# DF-1716 — nata ata-pci.c OOB interrupt[] write/read

## Verdict
**REPRODUCED (logic/harness)** — bug confirmed by source trace and a
userspace harness that simulates the exact `interrupt[8]` layout and the
attach/IRQ loops. The bug is *real* but **not live-triggerable on the
default QEMU guest**: the guest has no AHCI controller (NATA binds to the
PIIX3 IDE controller with 2 channels) and reaching `channels > 8` requires
a malicious / hotplug AHCI controller reporting CAP.NP > 7 or PI bits
8..31 set. On such a controller the bug yields up to 384 bytes of heap
OOB write on attach and OOB function-pointer read+indirect-call on every
IRQ; with no SMAP/SMEP/KASLR + heap grooming this is RIP control.

## Mechanism (path:line)
* `sys/dev/disk/nata/chipsets/ata-ahci.c:101-103` —
  `ctlr->channels = MAX(flsl(ATA_AHCI_PI), (ATA_AHCI_CAP & ATA_AHCI_NPMASK)+1)`
  sets channels up to 32 from hardware registers.
* `sys/dev/disk/nata/ata-pci.h:64-67` — `struct { void (*function)(void*); void *argument; } interrupt[8];`
  is hard-coded to 8 slots.
* `sys/dev/disk/nata/ata-pci.c:230` — attach loop adds `ctlr->channels`
  children (up to 32).
* `sys/dev/disk/nata/ata-pci.c:383-384` — `ata_pci_setup_intr` writes
  `controller->interrupt[unit].function/.argument` with no bounds check
  on `unit` against 8.
* `sys/dev/disk/nata/ata-pci.c:584-586` — `ata_generic_intr` iterates
  `unit < ctlr->channels`, reads `interrupt[unit].argument`, then calls
  `interrupt[unit].function(ch)` — OOB read + indirect call on every IRQ.

For `channels = 32`, units 8..31 each touch 16 bytes of OOB heap
(24 × 16 = 384 bytes).

## Phase 6 escalation
A live escalation chain on the default guest is **not possible**: there is
no AHCI device on the QEMU PIIX3-only config, and NATA binds to the legacy
IDE controller with 2 channels. The realistic trigger is a malicious /
hotplug PCIe AHCI device (Thunderbolt, crafted QEMU command line). This
is a valid external-device threat model, not an unprivileged-user
privesc. With such a device the OOB function-pointer read in
`ata_generic_intr` is direct RIP control (no SMEP, user pages executable),
so the chain would be: spray attacker-shaped heap content where the
controller's OOB interrupt[] region is read, place a userspace
`commit_creds(prepare_kernel_cred(0))` trampoline at the address the OOB
`function` field reads, wait for the next IRQ. We did not develop that
chain because it requires the malicious-device precondition the default
guest cannot supply.

## PoC
`harness.c` simulates the controller struct, attach loop, and IRQ loop
with `channels = 32`. Reports 24 OOB writes (Phase 1) and 24 OOB
function-pointer reads+indirect-calls per IRQ (Phase 2).

```
=== DF-1716 nata AHCI OOB interrupt[] harness ===
ctlr->channels = 32 (from CAP.NP+1 / PI), interrupt[] size = 8 slots
Phase 1 result: 24 OOB writes performed (expected 24 for channels=32)
Phase 2 result: 24 OOB-read+call per IRQ (expected 24 for channels=32)
VERDICT: BUG CONFIRMED. AHCI reporting 32 channels causes 24 OOB writes on
attach and 24 OOB function-pointer reads+calls per IRQ (384 bytes heap
corruption, full RIP control with heap grooming).
```

Build: `cc -O2 -Wall -Wextra -o harness harness.c` · Run: `./harness`

## PoC changes
Original folder had no source. Wrote `harness.c`, `build.sh`, `run.sh`,
this `VERDICT.md`, `manifest.json`, and `fix.diff`.

## Fix
`fix.diff` clamps `ctlr->channels` to 8 in `ata_pci_attach` after the
chip-init returns, before the child-attach loop runs. This is the
smallest change that bounds both the attach writes and the IRQ reads
without reworking the fixed-size `interrupt[]` array. Validated by a
clean `nativekernel` rebuild (nata is in GENERIC).