DF-3314 — node teardown dereferences the freed vap when the last node reference outlives vap destruction

File: sys/netproto/802_11/wlan/ieee80211_node.c (pass-2 audit, GLM 5.3)

What

struct ieee80211_node caches a back-pointer to its owning vap (ni->ni_vap). When a vap is destroyed, ieee80211_node_vdetach() (:203) → ieee80211_node_table_reset() (:1977) drops the table reference of every node of that vap, and the driver then frees the vap memory (ic_vap_delete). Any node that still has other references survives — unlinked (ni_table = NULL) but alive — and its eventual final ieee80211_free_node() walks a free path that dereferences the freed vap in three places:

1. _ieee80211_free_node() :1786-1790 — vap = ni->ni_vap; if (vap->iv_aid_bitmap != NULL) IEEE80211_AID_CLR(vap, ni_associd) — a pointer read from freed memory followed by a bit-clear write through it. (node_reclaim() :1909-1938 unlinks the node without clearing ni_associd; only node_leave() / node_cleanup() clear it, and neither runs for the bss node of a vap being destroyed: table_reset only does ia_node_leave + AID_CLR and leaves the field set.)
2. node_free() :1117 — ieee80211_ratectl_node_deinit(ni) derefs ni->ni_vap->iv_ratectl (proved live: with defect 1 alone patched, the panic moved to node_free+0x18).
3. node_free() :1118 → node_cleanup() :1033+ — vap->iv_opmode (:1041), vap->iv_ps_sta-- (:1042), vap->iv_set_tim (:1082), …

The code's own comment at :1774-1779 admits the hazard ("NB: careful about referencing the vap as it may be gone if the last reference was held by a driver") — but the derefs happen anyway. (Same code exists upstream in FreeBSD net80211.)

Who holds the last reference

Any in-flight frame: ic_raw_xmit(ni, …) mgmt output and M_ENCAP data frames carry a node ref that the driver drops at tx-complete. On async radios (ath, iwn, …) completions lag; destroying/resetting a vap under traffic leaves the window open. The PoC emulates exactly this with a software-radio KLD whose raw_xmit parks its node references and "completes" them after ifconfig destroy.

Reproduction (stock INVARIANTS guest, kernel #0)

Software radio fw3.c (DF-3282/3286/3312 harness pattern):

1. kldload fw3.ko; STA-mode vap up: ifconfig wlan create wlandev fw3_0 wlanmode sta ssid fw3sta mode 11g channel 1 up.
2. sysctl kern.fw3_sta=1 — the vap's bss node gets ni_associd = 0xc001 (exactly what ieee80211_recv_assoc, sta.c:1683, assigns after a completed MLME association) and one+ driver-held refs are parked (in the wild: any in-flight frame).
3. ifconfig wlan0 destroy — vap teardown runs; the bss node survives with ni_associd == 0xc001, ni_table == NULL; the 2640-byte vap block is kfree'd.
4. sysctl kern.fw3_spray=1 — reclaim the freed vap block with 0xb0 markers (proves the stale read pulls attacker-influenced memory).
5. sysctl kern.fw3_release=1 — the late "tx completions" drop the refs; the final ieee80211_free_node() executes:

fw3.release: late tx-complete of ni 0xfffff80118740400 (associd 0xc001, ni_vap 0xfffff80118718d00)
Fatal trap 9: general protection fault while in kernel mode
Stopped at      _ieee80211_free_node+0x2d:      andl    %esi,(%r8,%rax,4)

The faulting instruction is precisely IEEE80211_AID_CLR's aid_bitmap[aid/32] &= ~bit with %r8 = iv_aid_bitmap read from the freed (reused) vap. Reproduced twice from clean resets; one non-sprayed variant showed the silent form (stale pointer still mapped → bit-clear write into other freed memory, no trap) — the UAF occurs on every run, the fault depends on reuse.

Fix (validated)

fix.diff: at vap detach (ieee80211_node_table_reset), while ni_vap is still valid, run the full vap-dependent cleanup (ic_node_cleanup + ieee80211_ratectl_node_deinit) on every surviving node and mark it IEEE80211_NODE_VAPGONE; node_free() skips those calls for marked nodes (plus a belt-and-braces associd clear in node_reclaim()). Patched kernel (#1, 15:53:57): the exact PoC completes (RELEASE_RC=0), release log shows associd 0x0, guest stays up, dmesg clean. Stock kernel: fatal trap 9.

An earlier one-line fix (associd clear only) was insufficient — the panic moved to node_free+0x18 (ratectl deref), which is how defects 2 and 3 were proved.

Build / run

• sh findings/poc/DF-3314/build.sh — compiles the KLD in the guest (/root/fw3, make SYSDIR=/usr/src/sys).
• Baseline: load module → STA vap up → sysctl kern.fw3_sta=1 → ifconfig wlan0 destroy → sysctl kern.fw3_spray=1 → sysctl kern.fw3_release=1 → expect fatal trap 9 at _ieee80211_free_node+0x2d.
• Fix check: patch -p1 < fix.diff in guest /usr/src, make nativekernel && make installkernel, reboot, same sequence → no trap, guest survives.

DF-3314 VERDICT — reproduced (panic / kernel UAF wild write), fix validated

Status

• reproduced: 1 — Fatal trap 9 (general protection fault) at _ieee80211_free_node+0x2d (andl %esi,(%r8,%rax,4) = the IEEE80211_AID_CLR write through iv_aid_bitmap read from the freed vap), stock INVARIANTS kernel #0, from a fresh vm.sh reset with-src boot. Guest down at db> after the trap (vm.sh status => down).
• fix_status: fixed — with fix.diff (v2) applied in the guest and a rebuilt kernel (#1 15:53:57), the byte-identical PoC sequence completes: RELEASE_RC=0, associd 0x0 at every late completion, guest stays up, zero traps in dmesg, module unloads cleanly.

How the reproduction works

Threat model: a wifi driver whose tx completions can lag vap destruction (every async radio: mgmt output through ic_raw_xmit and M_ENCAP data frames each carry a node reference, dropped at tx-complete). The software-radio KLD (fw3.c) parks the references its raw_xmit receives and drops them on demand, i.e. a perfectly legal driver behaviour, just late.

1. STA vap up; its bss node is given ni_associd = 1|0xc000 — the exact value ieee80211_recv_assoc (sta.c:1683) assigns a station that completed MLME association. This is the one artificial step: it substitutes for driving the full AUTH/ASSOC exchange with a fake AP. Everything downstream is the genuine teardown path. (The AUTH/ASSOC exchange itself was implemented and exercised during the run — see "negative results" — proving the assoc state is normally reachable over the air; only the AP side had to be faked.)
2. ifconfig wlan0 destroy: ieee80211_vap_destroy → iv_vdetach → ieee80211_node_table_reset drops the table ref; the bss node survives (driver refs), ni_associd stays 0xc001; ic_vap_delete kfree's the 2640-byte vap block.
3. Marker spray reclaims the freed vap block with 0xb0 bytes.
4. Late tx-complete drops the last ref → _ieee80211_free_node reads ni_vap->iv_aid_bitmap = 0xb0b0b0b0b0b0b0b0 (non-canonical) → the bit-clear write GP-faults. Deterministic given reclamation of the freed block; without reclamation the same UAF write lands in whatever now occupies the stale target (silent corruption — observed once: 35 refs dropped, no trap, guest up).

Why the panic is not the whole story (primitive characterization)

• The faulting write is aid_bitmap[word] &= ~bit where the base pointer is read from freed-and-reclaimable vap memory. An attacker who can groom the 2640-byte M_80211_VAP-class heap so the stale iv_aid_bitmap field contains a chosen value gets a constrained arbitrary write: clear one bit of one 32-bit word at base + 4*(aid/32), aid ∈ [1, iv_max_aid) — i.e. a small fixed offset window set by the AID the vap allocated (attacker-influenced via association order). Repeatable per association/destroy cycle.
• Escalation to uid=0 from a bit-clear primitive was not achieved this run: candidates (credential cr_uid clear — wrong direction, needs bit SET; refcount zeroing — clear-only; pointer tag clearing — plausible but target-specific) all need a separate write or a set-gadget. The panic + demonstrated controlled-base write is the honest ceiling here. No KASLR/SMEP/SMAP on this guest, so the limit is the clear-only primitive, not hardening.
• Trigger preconditions keep severity at Medium: needs (a) a vap destroy/reset while (b) frame completions are still outstanding — routine admin under load on async-driver hardware; not directly forceable by an unprivileged local user, though any local user can be the traffic source.

Negative results recorded during verification (valuable)

• The "remote rates-IE heap overflow via node.c" candidate is DEAD. ieee80211_parse_beacon ends with IEEE80211_VERIFY_ELEMENT(rates, IEEE80211_RATE_MAXSIZE=15, …) (input.c:667) and every ieee80211_add_neighbor/ieee80211_init_neighbor caller checks the status (adhoc.c:697, mesh.c:1904, tdma.c:336); hostap.c:2061-2064 and sta.c:1666-1670 VERIFY_ELEMENT directly before setup_rates. Live proof on the guest: injecting a beacon with a 200-byte RATES IE into a running IBSS cell yields discard beacon frame, bad scan->rates len 200 and no overflow. DF-0581's "latent" classification stands.
• The AUTH/ASSOC injection harness worked on hostap (associd 0xc001 assigned to the attacker node), but the hostap destroy path clears ni_associd via node_leave → sta_leave → node_cleanup before the last ref can drop, so the hostap variant of this UAF does not fire; the STA-vap bss node is the vulnerable case (no node_leave ever runs for it — node_leave KASSERTs opmode != STA).

Kernel refs

• sys/netproto/802_11/wlan/ieee80211_node.c:1786-1790 (AID_CLR deref)
• sys/netproto/802_11/wlan/ieee80211_node.c:1112-1122 (node_free ratectl + cleanup derefs)
• sys/netproto/802_11/wlan/ieee80211_node.c:1033-1110 (node_cleanup vap derefs)
• sys/netproto/802_11/wlan/ieee80211_node.c:1909-1938 (node_reclaim unlink branch that strands ni_associd)
• sys/netproto/802_11/wlan/ieee80211_node.c:1977-2012 (table_reset — fix site)
• sys/netproto/802_11/wlan/ieee80211_sta.c:1683 (associd assignment)

Fix narrative

• v1 (associd clear in node_reclaim only): insufficient — rebuilt kernel trapped at node_free+0x18 (movq 0x30(%rax),%rax, the ratectl ni_vap deref). This usefully proved defects 2/3.
• v2 (fix.diff, validated): IEEE80211_NODE_VAPGONE flag; full vap-dependent cleanup at table_reset while the vap is alive; node_free skips cleanup for flagged nodes. Exact PoC passes; guest survives; module unloads. Recommend upstream also audits ic_node_cleanup callers-under-lock semantics for HT nodes (the PoC's node was legacy; node_cleanup is now additionally invoked under IEEE80211_NODE_LOCK from table_reset).

Guest

• baseline: DragonFly 6.5-DEVELOPMENT #0: Thu Jul 2 06:02:54 UTC 2026 (X86_64_GENERIC) — stock INVARIANTS.
• patched: DragonFly 6.5-DEVELOPMENT #1: Thu Sep 10 15:53:57 UTC 2026 (fix.diff applied in-guest only; host sys/ untouched).
• guest left in clean state (vm.sh reset with-src, status up).

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.