DF-4889

iir_pci_attach maps BAR0 and immediately drives the i960 MPR register layout at fixed offsets 0x002c..0x3FC0 (magic write/read at 0x1000 at iir_pci.c:223-231, 0x2FC0-byte region clear at iir_pci.c:232-233) without ever checking rman_get_size(io) >= GDT_PCINEW_SZ (0x4000). A card with the probed IDs (0x8086:0x0600 / ICP 0x1119 range) but a short BAR0 → MMIO reads/writes past the resource mapping: panic, or a bulk zero-write of up to ~12KB into kernel memory following the mapping — before the magic read-back check can reject the card.

Hardware-gated finding — PoC not runnable on the audit guest (no such controller; pciconf -lv shows no 0x8086:0x0600 / 0x1119 device — see env.txt). Driver is compiled into the guest kernel (kldstat -v → 100 pci/iir), so the code path is live wherever the card exists.

Status: untested per the DF-4175 hardware-gated convention; the missing check is certain by inspection. Source citations in the pass-2 result block; full narrative in VERDICT.md; fix in fix.diff (size check right after bus_alloc_resource_any).

DF-4889 — iir_pci_attach uses fixed DPMEM offsets up to 0x3FC0 with no BAR0 size validation

Status: untested (hardware-gated — no matching controller on the audit guest; code gap certain by inspection). Severity: Low. Class: improper input validation → out-of-bounds MMIO access (CWE-125/CWE-787, device-memory variant).

Root cause (sys/dev/raid/iir/iir_pci.c)

iir_pci_attach maps BAR0 with bus_alloc_resource_any(dev, SYS_RES_MEMORY, &rid, RF_ACTIVE) (iir_pci.c:186-192) and immediately drives the i960 "MPR" register layout at fixed offsets, never comparing the mapped extent (rman_get_size(io)) against the layout size GDT_PCINEW_SZ (0x4000, iir.h:101):

• first access: bus_space_write_4(..., GDT_MPR_IC, GDT_MPR_MAGIC) at offset 0x1000 (iir_pci.c:223-224) followed by a read-back (iir_pci.c:225-226);
• interface-area clear: bus_space_set_region_4(..., GDT_I960_SZ, 0, GDT_MPR_SZ >> 2) — 0xBF0 words covering 0x1000..0x3FC0 (iir_pci.c:232-233);
• status/command doorbells at 0x2c/0x34, queue regs up to GDT_MPR_IC + GDT_S_INFO + 12 ≈ 0x1013 (iir_pci.c:236-301).

A card that enumerates with the probed IDs (Intel 0x8086:0x0600, or ICP vortex 0x1119:0x0100-0x02ff / 0x0300 — iir_pci.c:160-171) but declares BAR0 smaller than 0x4000 (a broken card, or a deliberately crafted PCIe device) causes every access past the mapped extent to land on the virtual page(s) after the resource mapping: unmapped → kernel page-fault panic; or mapped for another purpose → wild kernel-memory reads/writes at fixed offsets past the mapping (the 0x1000..0x3FC0 region clear at iir_pci.c:232-233 is a bulk write of zeros over up to 12KB past a short BAR).

The magic read-back at iir_pci.c:225-231 catches most broken cards if the first write/read at 0x1000 happens to fault or read back garbage — but with a short BAR whose following virtual page is writable kernel memory, the write at :223 already corrupted that page before the check, and the read-back may return exactly the magic just written, passing the check and proceeding to the 0x2FC0-byte zero-clear.

Threat model

Attacker must control PCIe-enumerated hardware (evil device, DMA-attached card, or a misbehaving/counterfeit RAID card) — a physical/supply-chain trigger, hence Low. No path from an unprivileged user. Same trigger band as sibling hardware-gated raid findings (DF-4172 etc.).

Fix

See fix.diff: require rman_get_size(io) >= GDT_PCINEW_SZ right after mapping (and, with DF-4888's fix, the BAR is properly released when the check fails).

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.