DF-1124 — Signed integer underflow + OOB read in iwn5000_rx_calib_results (Intel WiFi)

Finding

iwn5000_rx_calib_results at sys/dev/netif/iwn/if_iwn.c:3364:

len = (le32toh(desc->len) & 0x3fff) - 4;

• len is a signed int. If (desc->len & 0x3fff) < 4, underflows to negative → kmalloc((size_t)len) = huge → ENOMEM (caught at :3396).
• If firmware reports e.g. masked len = 16380, len = 16376; kmalloc succeeds, then memcpy(sc->calibcmd[idx].buf, calib, len) at :3405 reads 16376 bytes from calib = desc + 1 inside a 4 KiB RX mbuf → up to ~12 KiB OOB read (info leak / panic). The calibcmd buffer is later replayed to runtime firmware via iwn5000_send_calibration.

Reachability on this guest

NOT reachable. No Intel WiFi adapter is present. if_iwn.ko is loadable but never attaches. The bug requires buggy/compromised firmware or DMA injection. Latent.

A userspace harness demonstrates both the underflow case and the OOB-read case for various firmware-supplied lengths.

Build / Run / Expected

cc -O2 -o harness harness.c     # build.sh
./harness                        # run.sh
# Expected: shows underflow (-4 → kmalloc(18446744073709551612)) and
#           OOB read (len=16376 from 4096-byte mbuf → 12288 bytes OOB)

Files

• harness.c — demonstrates underflow and OOB-read for 4 firmware-length cases.
• fix.diff — adds if (len < 0 || len > (int)(IWN_RBUF_SIZE - sizeof(*desc))) return;.
• build.log / run.log / env.txt — captured outputs.

VERDICT — DF-1124

Verdict: REPRODUCED (primitive) / NOT REACHABLE on guest (HW-gated)

The cited bug is real and confirmed by source trace + userspace demonstration of both the underflow and OOB-read cases. It is a latent info-leak / panic primitive requiring an Intel WiFi adapter and buggy/compromised firmware or DMA injection.

Mechanism (confirmed path:line)

1. iwn5000_rx_calib_results (sys/dev/netif/iwn/if_iwn.c:3350-3406) processes a calibration result notification from the firmware.
2. :3364: len = (le32toh(desc->len) & 0x3fff) - 4; — len is a signed int. The masked desc->len comes from the firmware/DMA and is untrusted.
3. Underflow case: if (desc->len & 0x3fff) < 4, len goes negative. kmalloc(len, ...) at :3395 promotes len to size_t → enormous allocation → ENOMEM (caught at :3396, returns). Benign for tiny masked lens.
4. OOB-read case: if firmware reports e.g. masked len = 16380, len =
5. kmalloc(16376) succeeds. Then memcpy(sc->calibcmd[idx].buf, calib, len) at :3405 reads 16376 bytes starting at calib = desc + 1 which lives inside a 4 KiB (IWN_RBUF_SIZE) RX mbuf cluster → reads up to ~12 KiB past the mbuf boundary. The calibcmd buffer is later replayed to runtime firmware via iwn5000_send_calibration, providing a data-exfiltration path.

Reproduction (userspace harness)

The harness exercises four firmware-length scenarios: - masked=0 → underflow to len=-4 → kmalloc(18446744073709551612) → ENOMEM - masked=3 → underflow to len=-1 → kmalloc(18446744073709551615) → ENOMEM - masked=16380 → len=16376 → 12288 bytes OOB read past 4 KiB mbuf - masked=200 → len=196 → benign (within mbuf)

Impact ceiling

• Per-call: up to ~12 KiB kernel heap OOB read, contents exfiltrated to firmware via calibration replay → info leak. On default GENERIC (INVARIANTS ON), the OOB read may hit a poisoned/poison-checked slab and panic; on noinv it's a silent info leak.
• Privilege: requires Intel WiFi adapter + malicious firmware or DMA injection (attacker controls the wire). Not a local unpriv path.
• Realistic: remote via compromised firmware/PCIe; niche.

Fix

fix.diff clamps len both ways after computing it:

if (len < 0 || len > (int)(IWN_RBUF_SIZE - sizeof(*desc)))
    return;

IWN_RBUF_SIZE = 4096 (if_iwnreg.h:54). The upper bound is exactly the bytes available in the RX mbuf after the desc header, since calib = desc + 1.

Validated: if_iwn.ko builds with RC=0 after applying the fix.

Fix validation

• Patch applies cleanly: Hunk #1 succeeded at 3362.
• make in sys/dev/netif/iwn/ → all firmware modules + if_iwn.ko linked, IWN_RC=0.
• Cannot boot-test (no Intel WiFi); fix_status: not_testable.

PoC changes

• harness.c written from scratch. Demonstrates four firmware-length scenarios showing both the underflow-to-ENOMEM and the OOB-read-of-12288 cases.