# DF-1239 — iwi_frame_intr framelen bound too loose (up to 28B heap leak)

## Verdict: NOT REPRODUCED (dead code at runtime — no hardware)

## Mechanism (source-level, confirmed real)

`iwi_frame_intr()` at `sys/dev/netif/iwi/if_iwi.c:1238` processes received
802.11 frames. The firmware-supplied frame length is bounded too loosely:

```c
// line 1248-1249
framelen = le16toh(frame->len);
if (framelen < IEEE80211_MIN_LEN || framelen > MCLBYTES) {
    ...
    return;
}
```

The DMA map is loaded with only `MCLBYTES` (2048) bytes (line 1287-1288):
```c
error = bus_dmamap_load(sc->rxq.data_dmat, data->map,
    mtod(mnew, void *), MCLBYTES, iwi_dma_map_addr, &data->physaddr, 0);
```

But the mbuf length is set to include the 28-byte prefix:
```c
// line 1319-1320
m->m_pkthdr.len = m->m_len = sizeof(struct iwi_hdr) +    // 4 bytes
    sizeof(struct iwi_frame) + framelen;                  // 24 bytes + framelen
```

Then `m_adj(m, 28)` strips the prefix, leaving an mbuf claiming
`framelen` bytes of payload starting at cluster offset 28. For
`framelen` in `(2020, 2048]`, the window `[28, 28+framelen)` extends 1–28
bytes past the DMA-mapped cluster → `ieee80211_input` processes
**uninitialized kernel heap** as if it were frame data.

**Struct sizes confirmed:** `iwi_hdr` = 4B (4 × uint8_t, `__packed`),
`iwi_frame` = 24B (reserved1[2]=8 + 6×uint8 + signal/noise=4 + antenna/
control=2 + reserved2[2]=2 + len=2, `__packed`). Prefix = 28B.

Max safe `framelen` = `MCLBYTES - 28 = 2020`. The check allows up to 2048,
28 bytes too loose.

**The bug is real in source.** A malicious AP that sends a frame with
`frame->len` in `(2020, 2048]` causes 1–28 bytes of uninitialized kernel
heap to be passed to `ieee80211_input`.

## Why it cannot reproduce on this guest

`iwi` is the **Intel PRO/Wireless 2200BG/2915ABG** Mini-PCI WiFi driver.

- **NOT in X86_64_GENERIC**: only in LINT64.
- Available as `if_iwi.ko`, but **not loaded** on the guest.
- The QEMU guest has **no WiFi card at all** — `pciconf -l` shows only
  bridges, VGA, virtio-net, virtio-blk. QEMU does not emulate Intel 2200BG.
- Even if `kldload if_iwi` were run (requires root), no PCI device would
  match and the driver never attaches → no RX interrupt → no
  `iwi_frame_intr` → unreachable.

This is **valid hard blocker: dead/unreachable at runtime on this guest**.
The threat model is a malicious WiFi AP in radio range of a real system
with an Intel 2200BG/2915ABG card.

## Fix

`fix.diff` tightens the upper bound from `MCLBYTES` to
`MCLBYTES - sizeof(struct iwi_hdr) - sizeof(struct iwi_frame)` (=2020).
Compiled successfully as `if_iwi.ko`.

## Impact

- **On this guest**: none (dead code, no WiFi hardware).
- **On a real system**: up to 28 bytes of uninitialized kernel heap leaked
  to the 802.11 stack per malicious frame. Info leak (stack/heap residue)
  from a remote (radio-range) attacker. The `iwi` driver targets an old
  (2004-era) Mini-PCI card; real-world prevalence is low.