DF-3971 — rt2560 beacon-ring slot overwrite leaks the old beacon mbuf + node reference on every re-RUN transition (remotely pump-able in IBSS)

File: sys/dev/netif/ral/rt2560.c (pass 2, GLM 5.3)

What

RT2560_BEACON_RING_COUNT is 1 (rt2560reg.h:26) — one beacon slot. Each entry into IEEE80211_S_RUN (rt2560.c:811-824) allocates a fresh beacon mbuf, takes a node reference, and hands both to rt2560_tx_bcn, which stores them into the slot (1546-1547) without freeing whatever the slot still holds. Whenever RUN is re-entered while the interface stays up, the previous m and ni pointers are overwritten and leaked (one ~2KB mbuf cluster + one ieee80211_node ref, pinning the node table entry).

Re-RUN without a stop is a normal, remotely-drivable event in IBSS: any peer beacon with same SSID/channel and higher TSF forces a merge — ieee80211_node.c:610-637 (ieee80211_ibss_merge) → ieee80211_sta_join1 (ieee80211_node.c:427+) → ieee80211_new_state(vap, IEEE80211_S_RUN, -1) for non-STA opmodes. Each merge leaks. Additionally, when rt2560_tx_bcn fails (map load error — it frees the m itself), the ieee80211_ref_node taken at rt2560.c:820 is never dropped.

Impact

Unbounded kernel memory growth (mbuf clusters + pinned nodes) from an on-channel remote peer, after an admin has configured adhoc/hostap mode. No memory corruption. Low.

Build / Run

Hardware-gated (RT2560 NIC; guest has none — env.txt): cc trigger.c (informational) # on target: adhoc vap up; from a 2nd radio rotate adhoc BSSIDs with # increasing TSF; watch netstat -m / node count climb per merge.

Fix validation

fix.diff frees the slot's stale occupants in rt2560_tx_bcn (guarded by data->m != m0 / data->ni != ni so the beacon_expire reuse path — which re-loads the same m — is untouched) and drops the leaked ref on the tx_bcn error path in newstate. git apply --check clean; module rebuilt clean with -Werror on the guest (build.log).

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.