# DF-4982 — iir(4) `GDT_IOCTL_EVENT` double-fetch → OOB kernel read (memcmp/strcmp) with equality-oracle

## Build / run (on a host that actually HAS an iir HBA)

```
cc -O2 -Wall -o df4982_iir_evt_oracle df4982_iir_evt_oracle.c
./df4982_iir_evt_oracle /dev/iir0        # root, or operator once devfs rule grants the node
```

## Expected output (hardware present)

```
in-bounds  (size=16): MERGE
in-bounds  (mismatch): APPEND
OOB raced  (size=0xFFFF): APPEND/MERGE per probe   <-- 1-bit oracle per probe
```

The oracle: a probe where the first `k` bytes of the user buffer equal
`ebuffer[elastidx].event_data.eu[0..k-1]` makes `memcmp` read kernel byte
`eu[k]` (k may be far past the 16-byte union — through `severity`,
`event_string[256]`, the remaining ~73 KB of `ebuffer[]`, and adjacent
module statics). MERGE ⇔ guess at byte k was correct. Byte-wise kernel
.data/.bss disclosure at ≤256 probes/byte.

## Status on the reference guest

**Not runnable — no iir HBA.** Verified on the audit guest (see `env.txt`):
the iir driver is compiled into `X86_64_GENERIC`, but the QEMU PCI bus has
no vendor 0x1119 (ICP vortex) / Intel device 0x600 RAID controller, so
`iir_pci_probe()` never matches, `iir_attach()` never runs, `gdt_make_dev()`
is never called and `/dev/iir` does not exist. Every iir_ctrl.c ioctl path,
including this one, is unreachable there. The finding is proven by source
trace (VERDICT.md); severity Low because the primitive is additionally
gated by the root-only 0600 device node.

## Fix

`fix.diff` — copy the event struct in ONCE, clamp `size` to `sizeof(eu)`,
operate on the kernel copy, copy back out on exit.