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