DF-5254 — urtwn beacon mbuf use-after-free (disjoint lock domains)

What

urtwn_update_beacon() manipulates uvp->bcn_mbuf with the driver mutex (sc_mtx) released while it calls ieee80211_beacon_update() (sys/bus/u4b/wlan/if_urtwn.c:2206-2212). Two other paths free/replace that same mbuf under different (or no) lock domains:

• urtwn_setup_beacon() — m_freem(uvp->bcn_mbuf); uvp->bcn_mbuf = m; (if_urtwn.c:2168-2171), reached from urtwn_newstate() after it drops the net80211 com lock (IEEE80211_UNLOCK(ic), if_urtwn.c:2551) and takes sc_mtx. Runnable S_RUN re-entry is attacker-reachable in IBSS mode: a crafted beacon with a larger TSF triggers ieee80211_ibss_merge() → ieee80211_sta_join1() → full state-machine re-entry → RUN (netproto/802_11/wlan/ieee80211_node.c:610-630).
• urtwn_vap_delete() — m_freem(uvp->bcn_mbuf) with no lock at all (if_urtwn.c:840-841).

Meanwhile iv_update_beacon is invoked with the com lock held (e.g. ieee80211_set_tim(), netproto/802_11/wlan/ieee80211_power.c:310-318, driven by station power-save traffic — i.e. remotely paced) but not sc_mtx, and ieee80211_beacon_update() writes TIM/CSA fields into the mbuf. No lock orders the writer (A) against the freer (B/C): A holds com, B holds sc, C holds nothing → classic use-after-free write on an mbuf cluster (m_freem returns the cluster to the mbuf cluster pool immediately).

Reproduce

Hardware-gated on-guest (no RTL8188CUS/EU USB device attached to the QEMU guest, kldstat shows urtwn not loaded), so this pack contains a faithful two-lock-domain race simulation of the exact interleaving instead:

./build.sh          # cc -O2 -pthread -Wall -o race_sim race_sim.c
./run.sh            # 3-5 runs x 5s; exit code 3 == UAF write detected

Expected (observed 6/6 clean runs on the guest, unprivileged user):

[UAF-WRITE] thread A wrote into a freed beacon mbuf (gen NNN) --
   freed by concurrent setup_beacon/vap_delete while A was inside
   ieee80211_beacon_update() with sc_mtx released (if_urtwn.c:2206-2212)
RESULT: USE-AFTER-FREE WRITE reproduced
exit=3

run.2.log shows the vap_delete variant firing (C frees = 1).

Fix

See fix.diff: hold URTWN_LOCK(sc) across ieee80211_beacon_update() (matching the driver's own locking for urtwn_tx_beacon), and take URTWN_LOCK(sc) around the free in urtwn_vap_delete().

Files

• race_sim.c — pthread model of the interleaving (zone-allocator emulation, generation counters; stale-generation write == write-after-free)
• build.sh, run.sh, build.log, run.log, run.2.log, env.txt
• fix.diff, manifest.json, verdict.json

DF-5254 — VERDICT

Finding: use-after-free write on the urtwn beacon mbuf (struct urtwn_vap.bcn_mbuf) because urtwn_update_beacon() releases the driver mutex around ieee80211_beacon_update() while urtwn_setup_beacon() / urtwn_vap_delete() free-and-replace the same mbuf from lock domains that are not ordered against it.

Reproduced?

On-guest kernel impact: NOT reproduced — hardware-gated. The guest has no Realtek RTL8188CUS/EU/8192CU USB device (kldstat shows if_urtwn.ko present at /boot/kernel/if_urtwn.ko but not loaded; no USB WLAN NIC in usbdevs). urtwn_attach() cannot run, so the kernel race cannot be fired directly. Per the audit protocol this is recorded as inconclusive with strong simulated evidence.

Simulated evidence: reproduced 6/6 clean runs (100%). race_sim.c models the exact interleaving with three pthreads mirroring the three code paths:

A zone-allocator emulation (free-list + generation counters) marks a cluster dead at m_freem(); any subsequent write is a genuine write-after-free. Observed on guest (DragonFly 6.5-DEVELOPMENT, gcc 8.3, 6 vCPU, unprivileged user):

run.log   5/5 runs exit=3 (UAF write detected; gens 220,184,186,404,403)
run.2.log 1/1  exit=3, killer = thread C (vap_delete variant, "vap_delete frees (C): 1")

~200 newstate re-entries and ~5000 update iterations per 5s run are enough to hit the window every time; on real hardware the B path is paced by remote IBSS merge beacons and the A path by station power-save TIM updates (both attacker-controllable timing), so the window (the whole duration of ieee80211_beacon_update() on the old pointer, if_urtwn.c:2212) is realistic.

Why it is a bug (source trace)

1. sys/netproto/802_11/wlan/ieee80211_power.c:310-318 — ieee80211_set_tim() holds IEEE80211_LOCK(ic) (com) and calls vap->iv_update_beacon(vap, IEEE80211_BEACON_TIM).
2. sys/bus/u4b/wlan/if_urtwn.c:2196-2216 — urtwn_update_beacon(): takes sc_mtx (2196), ensures uvp->bcn_mbuf != NULL (2197-2205), releases sc_mtx (2206), then ieee80211_beacon_update(ni, uvp->bcn_mbuf, mcast) (2212) writes into the mbuf, then re-takes sc_mtx (2214) for urtwn_tx_beacon.
3. sys/bus/u4b/wlan/if_urtwn.c:2551-2552 — urtwn_newstate() drops the com lock before taking sc_mtx, so its call into urtwn_setup_beacon() (2161-2171: m_freem(uvp->bcn_mbuf); uvp->bcn_mbuf = m;) is not serialized against step 2 by either lock: A holds com (not sc), B holds sc (not com).
4. sys/bus/u4b/wlan/if_urtwn.c:2667-2676 — setup_beacon runs for both HOSTAP and IBSS opmodes on every S_RUN entry; IBSS S_RUN re-entry is remotely triggerable via ieee80211_ibss_merge() → ieee80211_sta_join1() (netproto/802_11/wlan/ieee80211_node.c:630).
5. sys/bus/u4b/wlan/if_urtwn.c:840-841 — urtwn_vap_delete() frees uvp->bcn_mbuf with no lock whatsoever (Race variant C).

ieee80211_beacon_update() writes TIM bitmap / seq / CSA values into the mbuf (netproto/802_11/wlan/ieee80211_output.c:3339+), i.e. the use-after-free is a write primitive into a freed mbuf cluster (2 KB), repeated at attacker-paced frequency. The twin of this bug family was confirmed in the if_run.c pass-2 audit (beacon lifecycle / disjoint-lock-domain).

Exploitability sketch (why High)

• Object: mbuf cluster (2 KB) in a global cluster pool — freed clusters are recycled aggressively on any network load, so the write lands in a live adjacent object quickly (cross-object corruption, not a write-to-free-page).
• Control: attacker controls when (TIM update pacing via PS traffic + merge beacons) and content partially (TIM bitmap bytes, beacon contents from the vap's own beacon template).
• Gate: needs a urtwn USB NIC in hostap/ibss operation; attacker is a nearby peer (IBSS: fully unauthenticated).
• Ceiling: kernel memory corruption from an unauthenticated remote peer → panic now, potentially more with cluster-pool grooming.

Fix validation

Not kernel-tested (no hardware on the guest). fix.diff keeps URTWN_LOCK(sc) held across ieee80211_beacon_update() and locks the free in urtwn_vap_delete(); the simulated harness run with the fix's locking (sc held across A's write phase) shows 0 detections by construction, since B/C can no longer free while A writes.

Bottom line

status: inconclusive (hardware-gated kernel PoC), reproduced=false, impact on-guest=none; the code-level defect is certain to exist from the source trace and the simulated interleaving reproduces the UAF write in 6/6 runs. Recommended severity: High (memcorrupt bucket).

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.