# DF-1173 — nataraid metadata parsers: OOB write on ar_softc.disks[]

## Finding
Multiple ATA-RAID metadata parsers use a firmware/disk-controlled `disk_number`
(u8, 0-255, or a sum of two u8s up to ~510) as a direct index into
`raid->disks[MAX_DISKS=16]` with **no bounds check**:

- HPTv2 RAID0/SPAN  `ata-raid.c:1806` → write at `:1861`
- HPTv2 RAID01      `ata-raid.c:1838` (`disk_number + array_width`, up to ~510)
- HPTv3             `ata-raid.c:2040/2046/2052/2058/2073` → write at `:2103`
- LSI v2            `ata-raid.c:2866` → write at `:3001`
- nVidia            `ata-raid.c:3121` (uses `meta->disk_number` directly)
- SII               `ata-raid.c:3588/3592` (derived from u8 fields)

`struct ar_softc` (`ata-raid.h:108`) places `disks[16]` immediately before
`toggle`, `rebuild_lba`, `lock`, `disk`, `devstat`, `cdev`, `pid` — so an
out-of-range `disk_number` overwrites a `struct lock` (deadlock/corruption),
a `cdev_t` pointer (arbitrary-kernel-address deref), and a `struct proc *`
(UAF), i.e. kernel memory corruption.

## Why harness (not live trigger)
`nataraid` IS compiled into `X86_64_GENERIC`, but:
1. The metadata parsers are gated by PCI vendor ID in
   `ata_raid_read_metadata()` (`ata-raid.c:1414-1480`): the nVidia parser only
   runs on PCI vendor `ATA_NVIDIA_ID`, HPT on `ATA_HIGHPOINT_ID`, SII on
   `ATA_SILICON_IMAGE_ID`, LSI on `ATA_LSI_ID`. The QEMU guest's only ATA
   controller is the **Intel PIIX3** (chip `0x70108086`), which routes to the
   Intel parser, not any cited vendor parser.
2. The guest has **no ATA hard disk** (`ad*`) — only a DVD-ROM (`acd0`) — and
   nataraid created no RAID arrays (`/dev/ar*` absent).
3. Even on matching hardware the trigger requires a crafted disk image whose
   metadata sector (`NVIDIA_LBA = total_secs - 2`, etc.) is attacker-written
   (e.g. a USB/external image `chown`'d to the attacker).

So the primitive is demonstrated at the **function level** with a userspace
harness that replicates the exact indexing the kernel performs.

## Build & run
```
./build.sh && ./run.sh
```

## Expected (bug present)
The harness reports the OOB index and which kernel fields (lock/cdev/pid
offsets) fall under the write, and exits non-zero. The OOB write is real; on
matching hardware with a crafted disk it corrupts the slab object past
`disks[15]`.