DF-1891 — Verification Verdict

Verdict: REPRODUCED (source-confirmed + index-harness)

The unbounded ctlr->channels from CAP/PI registers is confirmed at sys/dev/disk/nata/chipsets/ata-ahci.c:101-103. The harness reproduces the 192-byte OOB write into ctlr->interrupt[8] for a 32-port AHCI.

Mechanism

// ata-ahci.c:101-103
ctlr->channels =
    MAX(flsl(ATA_INL(ctlr->r_res2, ATA_AHCI_PI)),
        (ATA_INL(ctlr->r_res2, ATA_AHCI_CAP) & ATA_AHCI_NPMASK) + 1);

ctlr->channels is taken directly from HW registers with no upper bound. PI is a 32-bit port bitmap (flsl returns 0..32); CAP.NP is 5 bits (0..31 → +1 = 1..32). The downstream sink ctlr->interrupt[] is sized 8 (ata-pci.h:67, "XXX SOS max ch# for now"). When channels > 8 (e.g. PI=0xFFFFFFFF → flsl=32, or CAP.NP=0x1f → 32), ata_pci_setup_intr writes controller->interrupt[unit] (ata-pci.c:383-384) for unit = 0..channels-1, writing (channels-8)*sizeof(void*) bytes off the end. With channels=32: (32-8)*8 = 192 bytes OOB. ata_generic_intr (ata-pci.c:584-586) later reads these corrupted slots and CALLS through them as function pointers on every IRQ → kernel arbitrary code execution.

Trigger: a malicious/glitched PCIe AHCI device with CAP.NP=0x1f or PI=0xFFFFFFFF; VFIO PCI passthrough with a crafted AHCI BAR; custom QEMU ahci with ports=32; some legitimate server AHCI with >8 ports.

Harness evidence

DF-1891: ata_ahci_chipinit (ata-ahci.c:101-103)
  AHCI CAP.NP = 0x1f -> 32 ports
  AHCI PI     = 0xffffffff -> flsl = 32
  ctlr->channels = 32 (NO upper bound vs interrupt[8])
  OOB interrupt[] writes = 24 entries x 8 bytes = 192 bytes past interrupt[8] into the controller struct
  Harness: simulated writes touched 24 trailer words (function pointers in real kernel)
  On real HW: ata_generic_intr (ata-pci.c:584-586) later CALLS through these corrupted pointers on every IRQ -> arbitrary kernel code exec.

Why no live trigger on this guest

The audit guest's AHCI controller (the emulated QEMU ahci on the primary disk) reports a small number of ports, so channels <= 8 and the OOB doesn't fire. Triggering requires a malicious AHCI BAR (passthrough / custom QEMU / specific server HBA). Valid Phase-6 hard blocker.

Exploit chain

Not applicable (needs malicious AHCI HW). No uid=0 claim. Live ceiling on vulnerable HW: 192-byte heap OOB write + function-pointer call on every IRQ → arbitrary kernel code execution / panic.

PoC changes

• Added harness.c: flat model showing 192-byte OOB into interrupt[].
• Added fix.diff: cap channels at nitems(ctlr->interrupt).

Fix

fix.diff adds ctlr->channels = MIN(ctlr->channels, nitems(ctlr->interrupt)) right after the register-derived value is computed, capping at the actual sink array size.

• BEFORE: harness shows 24 OOB interrupt[] writes (192 bytes).
• AFTER: channels is capped at 8, no OOB.