Firmware ring indices used unmasked: iwi_tx_intr/iwi_rx_intr termination depends on a raw CSR-read index; an out-of-range value → non-terminating interrupt loop holding IWI_LOCK + wlan serializer (hard hang) and txq->queued int underflow

DF-3842 — iwi(4) trusts firmware ring indices without range validation: iwi_tx_intr() (if_iwi.c:1681-1694) and iwi_rx_intr() (if_iwi.c:1639-1668) compare a raw CSR-read index against a ring counter that is always taken modulo the ring size. An out-of-range index (hostile/buggy firmware or a wedged card) makes the loops non-terminating while IWI_LOCK and the wlan serializer are held -> hard system hang; the tx loop additionally re-completes already-completed slots (ni/m NULL, txq->queued int underflow).

WHAT TO LOOK AT trigger.c documentation harness with both loops quoted. fix.diff mask hw with % IWI_{TX,RX}_RING_COUNT at read time.

BUILD cc -O2 -o trigger trigger.c (compiles clean on the guest) RUN ./trigger (stub: hardware-gated path) EXPECT On hardware: wedge the card (e.g. rfkill toggle storm until a command timeout desynchronises the fw ring) or run hostile fw: the interrupt handler never returns; console dead; ping dies.

CALIBRATION Low / likely — needs fw/bus misbehaviour as the trigger, but the missing mask is unambiguous in source and every other driver in the tree masks or bounds-checks these reads.

DF-3842 VERDICT — status: inconclusive (hardware-gated), source-level: LIKELY

Source trace (if_iwi.c): iwi_tx_intr :1681 hw = CSR_READ_4(sc, txq->csr_ridx); / fw value / :1683 while (txq->next != hw) { :1684 data = &txq->data[txq->next]; / in-bounds / :1689 ieee80211_tx_complete(data->ni, data->m, 0); ieee80211_tx_complete() tolerates ni == NULL (sys/netproto/802_11/wlan/ieee80211_output.c:3680) and m_freem(NULL) is a no-op, so the second lap over the ring is "safe" per iteration — :1692 txq->queued--; / int underflow / :1693 txq->next = (txq->next + 1) % IWI_TX_RING_COUNT; (64) If hw >= 64 (or any value not in [0,64)), next cycles 0..63 forever and never equals hw: the interrupt handler spins holding IWI_LOCK and the wlan serializer -> hard hang (no timer, no second intr can make progress). iwi_rx_intr :1639-1667 has the identical pattern with IWI_RX_RING_COUNT (32) and additionally re-runs iwi_frame_intr over swapped mbufs each lap.

Preconditions: the firmware publishes an out-of-range read index — hostile fw, or a desynchronised/wedged card (the driver itself acknowledges fw desyncs: iwi_watchdog :2093 "device timeout" -> restart task). Reads of 0xffffffff from a vanished device are the classic source; note iwi_intr() guards only the INTR register against 0xffffffff (if_iwi.c:1733), not the ring index registers.

Why not reproduced: no iwi NIC on the audit guest (run.log). The hang is conditional on device misbehaviour, hence confidence "likely" rather than "certain" — the missing mask itself is unambiguous.

Severity: Low (DoS of the local system, preconditioned on fw/bus fault).

Fix: fix.diff — mask both index reads into the ring domain at read time. Fix validation: not possible on this guest — fix_status not_applicable.

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.