# DF-4172 — iir(4) iir_intr: unvalidated controller completion index → OOB gdt_ccb access

## Build / Run
There is **no userland trigger** for this finding: `ctx.istatus` is a byte read
directly from the controller's doorbell register (`gdt_mpr_get_status`,
sys/dev/raid/iir/iir_pci.c:402-407) and delivered to `iir_intr`
(sys/dev/raid/iir/iir.c:1522) from the bus interrupt / polling paths. The only
"trigger" is a controller (or a PCIe peer with the DPMEM window mapped) that
delivers a completion index of 126 or 127.

To document the hardware gate on the audit guest, run:

    sh gate_check.sh          # shows: no /dev/iir, no 0x1119/0x8086:0600 PCI device, iir never attached

Expected on hardware-less guest: `no iir/isp PCI device present`, `ls: /dev/iir*: No such file or directory`.

Expected on a machine with an Intel/ICP iir RAID controller whose firmware (or
an attacker with bus-master access) writes an out-of-range completion index:
`iir_intr` indexes `sc_gccbs[istatus-2]` up to 2 entries (~780 bytes) past the
124-entry array → OOB `gc_flags` read → either
`gdt_free_ccb()` SLIST corruption / NULL-deref (iir.c:661),
`gdt_sync_event()` dereferencing a garbage `gc_ccb` (iir.c:1715, 1804), or the
`GDT_GCF_IOCTL` completion writing through a garbage `gc_ucmd` (iir.c:1600-1632).

## Fix
`fix.diff` adds the missing range check (`istatus` must be in
[2, GDT_MAXCMDS+1]) before the array access.
