# VERDICT — DF-4706

**status: inconclusive (hardware-gated; QEMU does not emulate LSI
MegaRAID) · reproduced: 0 · analysis confidence: likely**

## Was it reproduced?
No — and it cannot be on this guest: `pciconf -l` shows no
0x101e/0x1000:1960 RAID controller and `/dev/amr*` does not exist, so
`amr_pci_attach` never runs (verified this run, see
`../DF-4705/guest_session.log`). `kldload amr` on the guest loads
nothing with a matching device. The defect is established by code
trace:

1. `amr_pci_attach` bzeros the softc (`amr_pci.c:195`) — every member
   NULL, including the `amr_get_work` function pointer
   (`amrvar.h:254`).
2. IRQ is allocated `RF_SHAREABLE|RF_ACTIVE` (`amr_pci.c:257-258`) and
   the handler connected (`amr_pci.c:263-265`) — from this instant the
   ISR is live for **any** device asserting the shared line.
3. `amr_pci_intr` (`amr_pci.c:461-470`) has no status check / no
   `AMR_STATE_INTEN` gate; it calls `amr_done(sc)` unconditionally.
4. `amr_done` (`amr.c:1782`) immediately dispatches through
   `sc->amr_get_work` — still NULL until `amr_attach` assigns it
   (`amr.c:206-216`, reached only at `amr_pci.c:346`).
5. → indirect call to address 0 → fatal trap, boot-time or
   kldload-time panic.

Window: the three `bus_dma_tag_create`s + `lockinit`s + three DMA
alloc/load rounds between `amr_pci.c:278-340` — milliseconds, extended
under DMA32 memory pressure. The interrupt need not be the amr card's
own (RF_SHAREABLE) — any co-line device (NIC, USB controller) firing
in the window panics the machine.

Not a re-report of DF-1820: DF-1820 is the teardown half
(`amr_pci_free` ordering, intr torn down LAST while DMA is freed);
this finding is the setup half (intr registered FIRST, before the
dispatch table it calls exists). Different lines, different fix.

Also note the same unguarded handler is why DF-1820's teardown window
is exploitable — a complete fix gates `amr_pci_intr` on driver state
and fixes BOTH orderings; `fix.diff` here moves setup_intr after
`amr_attach()` and adds the `AMR_STATE_INTEN` gate.

## Exploit chain
None beyond DoS (NULL function-pointer call → panic). The called
address is fixed (0), not attacker-chosen; no control over registers
at the call site beyond `sc`.

## Fix validation
Impossible on this guest (no amr hardware → neither baseline nor
patched kernel can exercise the path). `fix_status: not_testable`.

## Guest state
Guest untouched; stayed up the whole run.

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