# DF-3867 — `emu_intr()` NULL-check/call race on `ihandler[].irq_func`

**File:** `sys/dev/sound/pci/emu10kx.c:993-999` (racy consumer),
`emu10kx.c:948-978` (unregistering side).

Verification was **not attempted at runtime** (contract skip for Low /
speculative findings) and is additionally blocked by the same hardware gate
recorded in the DF-3866 pack: this QEMU guest has no Creative Labs PCI
device, so the driver never attaches and no /dev/dsp exists.

## Build / run (on real hardware)

```sh
cc -O2 -o trigger trigger.c
./trigger /dev/dsp0
```

Expected on vulnerable hardware: kernel panic (call through NULL
`irq_func`) within minutes-to-hours of racing; on patched kernel: run
completes with "no panic occurred".

## Defect summary

`emu_intr()` is registered `INTR_MPSAFE` (emu10kx.c:3208) and takes no
lock while iterating `ihandler[]`. `emu_intr_unregister()` (under
`sc->lock`) NULLs `.irq_func`/`.softc` at emu10kx.c:966-967. The
check-then-call pair at emu10kx.c:994-997 loads `irq_func` twice with no
atomicity — a rec-channel STOP (unprivileged, via /dev/dsp) racing the
card's own IRQ delivery can call a just-NULLed function pointer →
guaranteed panic. Not memory-corruption exploitable (control-flow goes to
address 0); DoS only.