DF-3470 — net80211 ratectl registry has no in-use accounting: kldunload of a

rate-control algorithm in use leaves every vap's iv_rate dangling into

unmapped module text

What

sys/netproto/802_11/wlan/ieee80211_ratectl.c keeps static const struct ieee80211_ratectl *ratectls[IEEE80211_RATECTL_MAX] and hands raw pointers (vap->iv_rate = ratectls[type], ieee80211_ratectl.c:152) to vaps, which are then invoked through unprotected inline wrappers on hot paths (ieee80211_ratectl.h:69-124: ir_rate on every TX, ir_node_init on association, ir_node_stats via the world-readable net.wlan.<n>.rate_stats sysctl handler at ieee80211_ratectl.c:127-129 / 88-116, ir_deinit during vap detach).

ieee80211_ratectl_unregister() (ieee80211_ratectl.c:66-71) blindly NULLs the registry slot; it neither checks for nor prevents unload while vaps still reference the algorithm. The intended guard exists in the module glue — _IEEE80211_POLICY_MODULE (sys/netproto/802_11/ieee80211_dragonfly.h:316-336) refuses MOD_UNLOAD with EBUSY when nrefs != 0 — but the rate-control algorithm modules never increment it:

• sys/netproto/802_11/wlan/ieee80211_amrr.c:77 — static int nrefs = 0; and nothing else (grep: single occurrence).
• sys/netproto/802_11/wlan/ieee80211_rssadapt.c:97 — same.
• sys/netproto/802_11/wlan/ieee80211_ratectl_none.c:96 — same.

Contrast with the modules that got the pattern right: sys/netproto/802_11/wlan_wep/ieee80211_crypto_wep.c:108,118-119 (nrefs++ / nrefs-- in attach/detach) and sys/netproto/802_11/wlan/ieee80211_scan_sta.c:178,195-196. amrr is the default algorithm (ieee80211_ratectl.c:121-122).

Consequence

kldunload wlan_amrr (or wlan_rssadapt / a module-built wlan_none) while any vap exists succeeds (nrefs==0), unmaps the module, and leaves vap->iv_rate pointing into unmapped memory. The next rate-control operation — an unprivileged sysctl net.wlan.0.rate_stats read, any packet TX, a new association, or vap teardown — performs an indirect call through the dangling table: deterministic panic (execute-after-unmap). If the vacated module address range is subsequently reoccupied by another kldload, the call target becomes attacker-influenced module content. amrr is the default ratectl, so every vap on a system where wlan_amrr is a loadable module is exposed.

Verification status on the guest

Code-certain, runtime-not-demonstrable on this guest, honestly inconclusive:

• the guest kernel has wlan_amrr compiled in (kldstat -v lists it under kernel id 1; kldunload wlan_amrr -> "can't find file"), so the unload cannot even be attempted;
• the guest has no 802.11 hardware, so no vap can be created to hold iv_rate = &amrr (see VERDICT.md).

The mechanism is fully established by source: the guard exists, the increment is missing in exactly the three rate-control modules, and the registry (this file) provides no backstop.

Files

• analysis.txt — the decisive greps (guest + tree)
• VERDICT.md — full narrative
• verdict.json — machine verdict (status: inconclusive)

DF-3470 — VERDICT

Status: inconclusive on this guest (code-certain from source; impact by construction: panic / execute-after-unmap). Confidence: likely.

The defect

1. ieee80211_ratectl_set() stores a raw pointer into a loadable module into every vap: vap->iv_rate = ratectls[type] (sys/netproto/802_11/wlan/ieee80211_ratectl.c:152). All later use is via unguarded inline indirect calls (sys/netproto/802_11/ ieee80211_ratectl.h:69-124), including the world-readable rate_stats sysctl attached in this file (ratectl.c:127-129, handler at 88-116) and ir_deinit on vap teardown.
2. ieee80211_ratectl_unregister() (ratectl.c:66-71) has no in-use accounting: it NULLs the slot unconditionally when a module unloads.
3. The module glue _IEEE80211_POLICY_MODULE (sys/netproto/802_11/ieee80211_dragonfly.h:316-336) does implement the right guard — if (nrefs) ... error = EBUSY on MOD_UNLOAD — but the three rate-control algorithm modules declare static int nrefs = 0; and never increment it (ieee80211_amrr.c:77 — the default algorithm, ieee80211_rssadapt.c:97, ieee80211_ratectl_none.c:96), while sibling modules show the intended pattern (wlan_wep/ieee80211_crypto_wep.c:108/118-119, ieee80211_scan_sta.c:178/195-196).

So kldunload wlan_amrr (or rssadapt / none, where built as modules) succeeds while vaps actively use the algorithm: the module unmaps and every vap->iv_rate on the system dangles. The next ratectl operation (TX → ir_rate, association → ir_node_init, an unprivileged sysctl net.wlan.0.rate_stats read → ir_node_stats, vap detach → ir_deinit) is an indirect call into unmapped text → deterministic panic; with the address range later reoccupied by another kldload, the call target becomes attacker-influenced module content.

Why runtime reproduction was not possible on this guest

• The guest kernel has wlan_amrr compiled in (kldstat -v lists it under kernel id 1; kldunload wlan_amrr → "can't find file"), so the unload precondition cannot be created.
• The guest has no 802.11 hardware (QEMU vtnet only) — no vap can be attached, so no iv_rate = &amrr user exists to dangle. All DF wifi drivers require PCI/USB radio hardware.

Honest classification: inconclusive — mechanism and guard-bypass proven from source (analysis.txt), impact (panic) follows by construction, but not demonstrated end-to-end on this guest.

Recommended fix (two layers)

1. Arm the guard: each algorithm's ir_init/ir_deinit (or the registry) must maintain nrefs exactly like wlan_wep does — or better, move the counter into the registry: ieee80211_ratectl_register/unregister track per-type user counts (incremented in ieee80211_ratectl_set, decremented when a vap switches away / detaches) and ieee80211_ratectl_unregister() refuses (leaves the module loaded) while users exist.
2. Defense in depth: ieee80211_ratectl_unregister() should never run while vaps reference the algorithm; at minimum kprintf loudly and leak the registration rather than dangle every vap.

Fix validation

Not performed: the trigger cannot be constructed on this guest (no wifi hardware; algorithm compiled in). fix_status: not_testable.

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.

(No fix.diff for this item: documented recommendation only - see Fix above.)