# DF-3967 verdict — likely device-fed desync, Low

## Reproduced?
No Ralink NIC on the guest (env.txt).

## Analysis
- rt2661reg.h:191 `RT2661_TX_QID(v) ((v>>8)&0xf)` → 0..15;
  rt2661.c:906 `txq = (qid <= 3) ? &sc->txq[qid] : &sc->mgtq;` — qid 4 is the
  intended mgt id, 5..15 are garbage yet indistinguishable from mgt.
- rt2661.c:909 `data = &txq->data[txq->stat]` — completion is matched to the
  driver's *sequential* cursor, not to any device-provided index; any device
  reordering/duplication desyncs stat from the true completion order.
- rt2661.c:955 `txq->queued--` unguarded; gate at 1687 compares
  `queued >= RT2661_TX_RING_COUNT - 1` — negative queued never trips it, so
  cur laps next and slots owned by the device are reused (1561-1562/1643-1644
  overwrite data->m/desc while DMA pending).
- rt2661.c:916-917: `if (ni == NULL) continue;` after `m = data->m;
  data->m = NULL;` — m is dropped, never freed (leak per spurious entry).
- Driver-fed cursors themselves are in-bounds (cur/next/stat wrapped at
  count), so the memory-safety exposure is strictly device-fed desync.

## Severity rationale
Low: requires a misbehaving device (same bar as DF-3749/DF-1312-class
findings); consequence is an mbuf UAF write window (device DMA into a freed
cluster) or resource exhaustion — real but hardware-gated.

## Fix
fix.diff: reject qid>4, free m on the ni==NULL path, floor the queued--.

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