# DF-4142 — wi_rx_intr ignores wi_read_bap() failure: uninitialized kernel heap delivered to the network stack / BPF

File: `sys/dev/netif/wi/if_wi.c` (Prism2/2.5/3 + Lucent Hermes driver)

## What

`wi_rx_intr()` (if_wi.c:1277) reads the firmware frame header with a
**checked** `wi_read_bap()` (:1293), then allocates an mbuf sized for the
firmware-supplied `wi_dat_len` (:1319-1343) and copies the frame body with
an **unchecked** one:

	if_wi.c:1356
	    wi_read_bap(sc, fid, sizeof(frmhdr),
	        m->m_data + sizeof(struct ieee80211_frame), len);
	    m->m_pkthdr.len = m->m_len = sizeof(struct ieee80211_frame) + len;

`wi_read_bap()` (if_wi.c:1901) returns an error when `wi_seek_bap()` times
out or the BAP reports `WI_OFF_ERR` (:1880-1895) — and, importantly, the
`CSR_READ_MULTI_STREAM_2` at :1913 may have transferred only part of `cnt`
words before the failure is noticed. On any such failure the mbuf tail
(`len` bytes minus whatever was actually read) is **uninitialized kernel
heap**, yet `m_pkthdr.len` is set to the full
`sizeof(struct ieee80211_frame) + len` and the frame is handed to
`ieee80211_input()` (:1390-1395) and to any BPF listeners via the normal
receive path.

Threat model (device-fed, per the audit charter): a malicious or faulty
Hermes/Prism firmware/PCIe device (the NIC DMA-feeds the FID and the BAP
state) that makes a mid-frame BAP read fail leaks stale kernel heap memory
(possible previously-freed packet data, key material, pointers) into frames
observable by root/operator via BPF and partially forwarded to the network.

Bounds note (this is NOT a length bug): `len` is correctly bounded —
`off + len > MCLBYTES` drops the frame (or zeroes `len` in monitor mode)
at :1326-1338, and the mbuf is cluster-backed when `off + len > MHLEN`;
the write stays within the mbuf. The defect is solely the ignored return
value → uninit-read info leak.

## Fix (fix.diff, applies clean, never applied to sys/)

Check the return, count the error, and drop the frame (mirroring the
adjacent error paths at :1293-1302 / :1344-1353).

## PoC

Not runnable on this guest: `wi(4)` requires PCMCIA/ISA/PCI Prism or Lucent
hardware; the QEMU guest has none (pciconf shows 0 wireless devices), and
the trigger additionally requires a device that fails a mid-frame BAP
transfer. Source-level proof only; see VERDICT.md.