DF-5292 — rum beacon mbuf write-after-free across disjoint lock domains

What

rum_update_beacon() (sys/bus/u4b/wlan/if_rum.c:2792-2831) drops RUM_LOCK at :2825 and then calls ieee80211_beacon_update(ni, m, mcast) at :2828, which WRITES seqno/capinfo/TIM/ERP element data into rvp->bcn_mbuf's 2 KB cluster while holding only the net80211 ic lock (net80211/wlan/ieee80211_output.c:3339 ff.). Two other paths free or replace that same cluster under disjoint lock domains:

• rum_newstate() — releases IEEE80211_LOCK(ic) at :932, takes RUM_LOCK(sc) at :933, and on S_RUN rum_alloc_beacon() (:977 → :2775-2778) does m_freem(rvp->bcn_mbuf) + replace, holding only the sc lock.
• rum_vap_delete() — m_freem(rvp->bcn_mbuf) at :715 with NO lock at all.

ic-lock vs sc-lock are disjoint ⇒ a free landing between :2825 and the end of the in-mbuf writes is a kernel write-after-free on a freed 2 KB cluster.

Twin of DF-5246 (if_run), DF-5254 (if_urtwn), DF-5259 (if_mtw).

Hardware gating

All rum(4) paths need an RT2501/RT2601 USB dongle to attach; the QEMU guest has none, so in-kernel reproduction is not possible. Evidence is (a) the line-level lock-domain trace above and (b) a userland interleaving model of the exact code regions and locks (rum_beacon_race.c), run 3×10 s on the guest. The struct/module if_rum.ko was kldload'ed on the guest to confirm the audited code is the running build (md5-identical source tree).

Build / Run / Expected

cc -O2 -pthread -Wall -o rum_beacon_race rum_beacon_race.c
./rum_beacon_race 10        # 3 runs

Expected: freed-in-window UAF WRITES > 0 in every run (reachability of the interleave); see run.log (1, 9, 3 hits in the first series; 5, 2, 13 in the preemption-mode series — the userspace floor; the in-kernel window is microseconds of TIM/element recompute and is unbounded under preemption).

Fix

fix.diff — hold RUM_LOCK across the beacon_update in-mbuf writes (and take it around the m_freem in rum_vap_delete). git apply --check clean. Kernel fix validation is hardware-gated (fix_status: not_testable).

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.