# DF-3971 verdict — certain lifetime leak (mbuf + node ref) per re-RUN; remotely pump-able in IBSS

## Reproduced?
No Ralink NIC on the audit guest (env.txt) — the leak could not be observed
at runtime. The source chain is complete and every link was traced:

- rt2560reg.h:26: `RT2560_BEACON_RING_COUNT 1` — single beacon slot; there is
  no completion handler for bcnq, so the only paths that clear slot 0 are
  reset_tx_ring (stop) and free_tx_ring (detach).
- rt2560.c:811-824 (newstate RUN): `ieee80211_beacon_alloc` + `ref_node` +
  `rt2560_tx_bcn` — on re-entry to RUN the slot is not checked or cleared.
- rt2560.c:1546-1547 (tx_bcn): `data->m = m0; data->ni = ni;` unconditional
  overwrite of slot 0's previous occupants → leak of old mbuf + old node ref.
- Re-RUN-without-stop is real: ieee80211_node.c:610-637 ibss_merge →
  ieee80211_node.c:427+ sta_join1 → `ieee80211_new_state(vap,
  IEEE80211_S_RUN, -1)` for non-STA opmodes — driven by any on-channel peer
  beacon with a greater TSF (the "oldest network wins" merge rule), so a
  remote party can cycle BSSIDs and leak once per merge. ic_nrunning never
  drops to 0 in this flow, so rt2560_parent never issues the stop/reset
  that would reclaim the slot.
- Error path: rt2560.c:820-823 — if tx_bcn fails (it m_freem()s the m
  itself at 1529-1534), the ref taken at 820 is never dropped.

Note what this is NOT: with RING_COUNT==1 there is no double-free / aliasing
(beacon_expire and tx_bcn share the same slot 0 and the same m), unlike the
multi-slot variant I also analyzed and killed. Pure resource leak, no memory
corruption — the pinned node keeps a valid bss referenced, so no UAF either.

## Fix
fix.diff: (1) in rt2560_tx_bcn, unload+free a stale slot occupant before
storing, guarded by `data->m != m0` / `data->ni != ni` so the beacon_expire
reload path (rt2560.c:1355-1368) which passes the *same* m/ni is unaffected;
(2) drop the leaked ref when tx_bcn errors in newstate. `git apply --check`
clean on sys/; applied on the guest /usr/src copy, if_ral.ko rebuilt clean
with -Werror (build.log). Runtime validation needs the NIC.

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