# DF-4809 — VERDICT

**Status: untested** (static-analysis finding; Phase V not applicable — no
runnable PoC exists for the trigger condition on the QEMU guest).

## Reproduced?

No, and deliberately not attempted. Triggering requires `ata_dmaalloc()`
(ata-dma.c:90-154) to fail for an AHCI channel at attach time, which requires
`bus_dmamem_alloc`/`bus_dma_tag_create` failure for 12 KB of DMA-coherent
memory — i.e. DMA-mappable memory exhaustion during device enumeration. There
is no unprivileged (or any) syscall path to force this from a running system;
it is a boot/hot-plug-time robustness defect. Per the audit contract
(Low/Info findings do not get guest verification) the QEMU guest was not used
for this finding.

## Why I am confident the bug is real anyway

The code path is fully static and unconditional:

- `ch->dma = NULL` is the documented failure exit of `ata_dmaalloc`
  (ata-dma.c:152-153) and attach proceeds afterwards.
- `ata_attach` → `ATA_RESET(dev)` → `ata_pcichannel_reset` calls
  `ctlr->reset(dev)` with no NULL guard (ata-pci.c:850-851) while guarding the
  adjacent DMA reset with `if (ch->dma)` (ata-pci.c:842).
- `ata_ahci_reset` immediately does `ch->dma->work_bus` (ata-ahci.c:467).

Impact ceiling: panic at attach/reinit (CWE-476). Not memory corruption, no
attacker-controlled data is involved; severity Low, confidence "likely" (path
certain; trigger constrained to resource exhaustion).

## Recommended fix

One-line guard in `ata_ahci_reset` (see fix.diff in this directory; authored
against the read-only `sys/` tree, never applied):

```c
if (ch->dma == NULL || ch->dma->work_bus == 0)
    return;
```

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