# DF-5292 VERDICT — beacon mbuf write-after-free (rum twin of DF-5246/5254/5259)

**Status: inconclusive (hardware-gated).  Bug: real, line-proven.**

## Reproduction path (in-kernel)

1. Attach rum(4) device, create `wlan0` in hostap or ibss mode, bring it up
   (S_RUN allocates the beacon via `rum_alloc_beacon`).
2. Drive `iv_update_beacon` (remote-assistable: TIM updates on station
   sleep/wake, ERP changes, CSA; local: ioctl-triggered beacon changes) —
   this enters `rum_update_beacon` on a net80211/serializer thread holding
   only the ic lock after :2825.
3. Concurrently force the other domain: `ifconfig wlan0 down` / re-run
   (`rum_newstate` → S_RUN → `rum_alloc_beacon` → `m_freem(old bcn)` under
   sc lock, :932-933/:2775-2778) or `ifconfig wlan0 destroy`
   (`rum_vap_delete` → `m_freem` at :715, no lock).
4. A free landing between :2825 and the end of `ieee80211_beacon_update`'s
   writes corrupts the freed 2 KB cluster (write-after-free).

## Why inconclusive on this guest
No USB passthrough, no RT2573 device model ⇒ rum(4) never attaches ⇒ the
vap/beacon lifecycle cannot be entered.  (Confirmed: source md5 on guest ==
audit tree; `kldload if_rum.ko` works; no hardware probe.)

## Simulated evidence
`rum_beacon_race.c` models the three threads with the exact lock protocol
(ic mutex, sc mutex; deleter lock-free).  Results (guest, 3×10 s):
1/9/3 UAF-write interleavings (base), 5/2/13 (with a mid-write yield modeling
scheduler preemption) — nonzero in 6/6 runs ⇒ the interleaving is reachable;
the userspace write burst is nanoseconds, while the in-kernel
`ieee80211_beacon_update` performs TIM bitmap recopy, trailer memmove and
element rebuilds (µs, preemptible), so the real window is strictly larger.

## Exploit chain (if hardware present)
hostap/ibss vap + power-save client TIM churn (remote-peer triggerable)
racing `ifconfig down/destroy` → `ieee80211_beacon_update` writes into a
freed 2 KB cluster → heap corruption → panic; with post-free reallocation
control (2 KB zone), controlled overwrite → potential privesc.

## Fix
Hold `RUM_LOCK(sc)` across the beacon_update write phase and around the
`m_freem` in `rum_vap_delete` (fix.diff; `git apply --check` clean).
Lock-order note: the fix takes sc while ic is held (ic→sc), which is the
established direction in this driver (rum_update_promisc, rum_wme_update);
`RUM_LOCK` is LK_CANRECURSE so the nested `rum_set_channel` path inside CSA
completion is safe.  Not kernel-testable without hardware.

## Kernel references
- sys/bus/u4b/wlan/if_rum.c:2800 (m = rvp->bcn_mbuf, ic domain only)
- sys/bus/u4b/wlan/if_rum.c:2803-2825 (sc lock taken/dropped)
- sys/bus/u4b/wlan/if_rum.c:2828 (ieee80211_beacon_update writes into m)
- sys/bus/u4b/wlan/if_rum.c:932-933 (ic lock dropped, sc lock taken)
- sys/bus/u4b/wlan/if_rum.c:977 → 2775-2778 (m_freem+replace under sc)
- sys/bus/u4b/wlan/if_rum.c:715 (m_freem with no lock)
- sys/netproto/802_11/wlan/ieee80211_output.c:3339-3470 (beacon_update writes)
- sys/netproto/802_11/ieee80211_dragonfly.h:598 (IEEE80211_LOCK = per-ic mutex)

## 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.