# DF-3581 — Unmasked firmware closed_count can wedge iwn_notif_intr() in an infinite loop

## Root cause (source-verified)

`sys/dev/netif/iwn/if_iwn.c:3900-4057` (`iwn_notif_intr()`):

```c
hw = le16toh(sc->rxq.stat->closed_count) & 0xfff;    /* if_iwn.c:3900 */
while (sc->rxq.cur != hw) {                           /* if_iwn.c:3901 */
        ... process notification at sc->rxq.data[sc->rxq.cur] ...
        sc->rxq.cur = (sc->rxq.cur + 1) % IWN_RX_RING_COUNT;   /* 64 */
}
```

`closed_count` is a firmware-written DMA value masked to 12 bits (0..4095),
but the RX ring has only `IWN_RX_RING_COUNT == 64` (1<<6) descriptors
(if_iwnreg.h:29-30) and `sc->rxq.cur` cycles modulo 64. **Any firmware value
in [64, 4095] can never equal `cur`**, so the loop never terminates: the
driver spins forever processing garbage "notifications" from the same 64
buffers, holding `sc->sc_lk` in the interrupt handler — the machine wedges
(hard hang / soft lockup, no panic, no watchdog output because the thread
never sleeps).

## Impact

Firmware-triggered hard hang (DoS). The iwn firmware is the driver's stated
trust boundary (same model as DF-1122); a firmware bug (register write
truncation, DMA corruption of `sc->rxq.stat`) or hostile firmware value
triggers it. No memory corruption: `sc->rxq.cur` stays in [0,63] and all
array indexing inside the loop uses bounded indices — the defect is purely
the non-terminating loop.

## Status

**untested** — requires an iwn device whose firmware delivers an
out-of-range closed_count; the QEMU audit guest is virtio-only. Source
analysis only (the loop-termination arithmetic is decidable on paper:
{cur mod 64} ∩ [64,4095] = ∅).

## Fix

Mask the firmware value to the ring size and/or bound the iteration count:

```c
hw = le16toh(sc->rxq.stat->closed_count) & (IWN_RX_RING_COUNT - 1);
```

(or bail out with a device reset when `hw >= IWN_RX_RING_COUNT`).