# DF-1210 — OOB read in AHCI DHRS error path (device-controlled CCS slot)

## Claim
`ahci_port_intr()` DHRS branch (`sys/dev/disk/ahci/ahci.c:2843-2851`):
`err_slot = AHCI_PREG_CMD_CCS(ahci_pread(...))` is a 5-bit value (0-31)
read from the AHCI controller, but `ap->ap_ccbs[]` is sized for
`sc->sc_ncmds` (4-32). The code does `ccb = &ap->ap_ccbs[err_slot]`
(`ahci.c:2847`) and derefs `ccb->ccb_xa.fis->command` (`ahci.c:2850`)
**before** any bounds check. The TFES path (`ahci.c:2724`) correctly
checks `err_slot < 0 || err_slot >= sc_ncmds` first; the DHRS path does not.
A malicious/buggy AHCI controller returning a CCS >= sc_ncms yields an OOB
`ap_ccbs[]` index then a deref of a garbage `fis` pointer → kernel panic /
controlled memory access.

## Verdict
**NOT TESTABLE on this audit guest** (real bug, traced line-by-line; fix
authored and compile-validated into the GENERIC kernel). See `VERDICT.md`.

## Why not reproduced here
- The guest has **no AHCI/SATA controller**: `pciconf -l` shows none; the
  disk is virtio-blk (`/dev/vbd0`). `ahci(4)` did not attach, so
  `ahci_port_intr()` is never called.
- Even with an AHCI controller present, the malicious value comes from the
  controller's CCS hardware register, not from any userspace syscall. The
  benign QEMU AHCI model always reports a valid CCS, so there is no
  unprivileged path to drive `err_slot >= sc_ncmds`.

## Trigger (threat model)
A malicious or faulty AHCI controller (PCIe peripheral, Thunderbolt
storage-bridge, or a malicious VM host's AHCI device model attacking a
guest) that raises a DHRS interrupt with `ERR` set and `CCS >= sc_ncmds`.
Common in the real world via buggy controllers and is a class of
DMA/peripheral attack surface.

## Fix
`fix.diff` mirrors the TFES bounds check (`err_slot < 0 || err_slot >= sc_ncmds`)
immediately after reading CCS and before the `ap_ccbs[err_slot]` deref,
routing a bad slot to the existing `process_error` machinery (which re-reads
CCS and the TFES path's check then resets the port).