DF-3836 — static channel-table pointer in bwn_phy_lp_b2063_switch_channel keeps the previous entry on lookup failure → radio silently tuned to the wrong channel

• File: sys/dev/netif/bwn/bwn/if_bwn_phy_lp.c (pass 2)
• Class: CWE-457 (stale state via static local) → wrong-frequency operation; success returned for an unsupported channel
• Severity: Low (reachability constrained: callers pass net80211-validated channel numbers, all of which are present in the table today; the bug turns any future/edge miss from a clean EINVAL into silent mistuning)
• Upstream-inherited: FreeBSD head has the identical static const struct bwn_b206x_chan *bc in bwn_phy_lp_b2063_switch_channel (their line 815); note their b2062 variant correctly uses a non-static local (their line 954), as does DragonFly's (line 926).

Build / Run / Expected

Hardware-gated (env.txt). Mental test, source-level:

call 1: bwn_phy_lp_b2063_switch_channel(mac, 36)   -> bc = &table[17], OK
call 2: bwn_phy_lp_b2063_switch_channel(mac, 9x)   -> 9x not in table; loop ends without
          match; bc STILL &table[17] from call 1 (static!) -> NULL check passes ->
          radio reprogrammed for channel 36's RF values, returns 0 (success)

Expected on vulnerable code: bwn_phy_lp_switch_channel then records plp->plp_chan = chan (the unhandled one) and writes it to BWN_CHANNEL — the stack believes it is on the new channel while the RF is on the old one (regulatory/interference hazard, association failure).

Root cause

if_bwn_phy_lp.c:792-808:

    static const struct bwn_b206x_chan *bc = NULL;   /* STATIC */
    ...
    for (i = 0; i < N(bwn_b2063_chantable); i++) {
            if (bwn_b2063_chantable[i].bc_chan == chan) {
                    bc = &bwn_b2063_chantable[i];
                    break;
            }
    }
    if (bc == NULL)
            return (EINVAL);

The static keyword makes bc persistent across calls, so the bc == NULL failure detection only works on the very first invocation. The sibling function bwn_phy_lp_b2062_switch_channel uses a plain (non-static) const struct bwn_b206x_chan *bc (line 926) — the intended form.

VERDICT — DF-3836

status: inconclusive (source-certain, hardware-gated) — reproduced: 0 — guest impact: none.

Defect demonstration (source-level)

bwn_phy_lp_b2063_switch_channel — if_bwn_phy_lp.c:792-808:

line 794: static const struct bwn_b206x_chan *bc = NULL; ← persistent storage lines 801-806: linear search; bc assigned only on match lines 807-808: if (bc == NULL) return (EINVAL); ← only detects first-call miss

Call sequence: switch(36) succeeds → bc = &bwn_b2063_chantable[17] forever. Any later switch(chan ∉ table): loop ends unassigned, bc != NULL, RF is programmed with channel 36's bc_data[] (lines 810-921), function returns 0. Caller (bwn_phy_lp_switch_channel:567-581) stores plp->plp_chan = chan and writes BWN_CHANNEL — divergent state.

Control: the b2062 sibling at line 926 uses const struct bwn_b206x_chan *bc = NULL; (no static) — the intended pattern; its bc == NULL check is sound.

Practical reachability

Callers pass ieee80211_chan2ieee(ic, ic->ic_curchan) (if_bwn.c:1911→4434) or the literal 7 (if_bwn_phy_lp.c:477, 1763). All net80211-regdomain channels currently exposed are present in the 58-entry table, so the stale path needs a future channel-set expansion or a half/quarter channel — hence Low. No memory-safety consequence (bc points into valid const data); impact is wrong-frequency operation.

Guest

No Broadcom wireless PCI device (env.txt); bwn never attaches; not exercisable.

Fix

Delete static (fix.diff, matches the b2062 form and FreeBSD's own b2062 function). git apply --check passes. Upstream FreeBSD carries the same static in its b2063 function (their line 815) and should receive the same fix.

Fix status (batch validation)

Applied with the 36 sibling fix.diffs of this batch in findings/poc/_batch41/all_fixes.patch; single in-guest make -j6 nativekernel KERNCONF=X86_64_GENERIC completed RC=0 with zero errors under -Werror (full log: findings/poc/_batch41/fix_build8.log). Behavior A/B intentionally skipped for this Info-tier item.