# 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.