# DF-1175 — VERDICT

**Verdict: REPRODUCED (source+harness, module-build-validated).** Not `uid=0` —
this is an **OOB read** with info-leak + DoS impact in optional legacy ATA
RAID metadata parsing.

## Bug confirmation

Two checksum loops in `sys/dev/disk/nata/ata-raid.c` use a disk-controlled
`u_int32_t config_size` field as their iteration bound against a small
fixed-size `kmalloc` buffer.

### Intel parser — `ata_raid_intel_read_meta` (line 2120)

```c
/* ata-raid.c:2132 */  meta = kmalloc(1536, M_AR, M_WAITOK | M_ZERO);
/* ata-raid.c:2145 */  if (strncmp(meta->intel_id, INTEL_MAGIC, ...)) goto intel_out;
/* ata-raid.c:2151-2154 */
for (checksum = 0, ptr = (u_int32_t *)meta, count = 0;
     count < (meta->config_size / sizeof(u_int32_t)); count++)
    checksum += *ptr++;
```

`config_size` is `u_int32_t config_size` at `ata-raid.h:307` (offset 56 in the
on-disk struct, populated by `ata_raid_rw`). The buffer is **1536 bytes** (384
u32 words). Any `config_size > 1536` over-reads; `config_size = 0xFFFFFFFF`
walks ~4 GB past the allocation before faulting.

### nVidia parser — `ata_raid_nvidia_read_meta` (line 3018)

```c
/* ata-raid.c:3028 */  meta = kmalloc(sizeof(struct nvidia_raid_conf), ...);
/* ata-raid.c:3039 */  if (strncmp(meta->nvidia_id, NV_MAGIC, ...)) goto nvidia_out;
/* ata-raid.c:3046-3048 */
for (checksum = 0, ptr = (u_int32_t*)meta, count = 0;
     count < meta->config_size; count++)
    checksum += *ptr++;
```

`config_size` is `u_int32_t config_size` at `ata-raid.h:592`. The buffer is
**512 bytes** (`sizeof(struct nvidia_raid_conf) == 512`, verified in-guest).
The loop reads `config_size` u32 words = `4 * config_size` bytes; a
`config_size` of 0x400 reads 4096 bytes (3584-byte over-read).

### Reachability without a valid checksum

Both parsers gate on the magic-string check (Intel:2145, nVidia:3039) **before**
the loop, but verify the checksum (Intel:2156, nVidia:3049) **after**. An
attacker needs only to satisfy the 8/24-byte magic; the loop faults (or
over-reads) before the checksum is compared.

## Reproducibility on the audit guest

- `nataraid` is `optional` (`sys/conf/files:143`), not in `X86_64_GENERIC`.
  The module ships at `/boot/kernel/nataraid.ko`.
- The QEMU guest uses virtio-blk (`vtblk0`), not ATA, so the parsers never run
  on guest disks. Live triggering would require rebooting QEMU with an added
  IDE/SATA disk image containing crafted metadata.

A userspace harness (`harness.c`) reconstructs both loops with the exact
kmalloc sizes (1536 / 512) and matching magics, and drives them with oversized
`config_size` values. Run on the guest:

```
=== Case 1: Intel parser ===
  meta = kmalloc(1536); magic OK; config_size = 0x10000 (65536)
  loop will run 16384 iterations, reading 65536 bytes (64000-byte OOB read)
  magic check: PASS
  (loop completed -- kernel equivalent: info leak of slab trailing bytes)

=== Case 2: nVidia parser ===
  meta = kmalloc(512); magic OK; config_size = 0x400 (1024)
  loop will run 1024 iterations, reading 4096 bytes (3584-byte OOB read)
  magic check: PASS
  (loop completed -- kernel equivalent: info leak of slab trailing bytes)
```

(Userspace `calloc`d buffers are fully mapped so no SIGSEGV; in the kernel,
a small over-read leaks slab-trailing bytes into the checksum, and a large
over-read walks into unmapped pages and panics.)

## Module build validation

The fix.diff was applied in-guest to `/usr/src` and `make` in
`/usr/src/sys/dev/disk/nata/nataraid` produced a clean `nataraid.ko`
(`RC=0`, `-Werror`). The patched source compiles. Source was then reverted.

## Exploit chain

`none` — pure OOB read; not a write primitive. Impact ceiling: small
info-leak of slab-trailing kernel heap bytes (would require a second primitive
to exfiltrate the checksum), plus reliable DoS panic via large `config_size`.

## Fix

`fix.diff` caps each loop's iteration count to the actual buffer size
(`1536/sizeof(u32)` for Intel, `sizeof(struct nvidia_raid_conf)/sizeof(u32)`
for nVidia). `git apply --check` passes against the audit tree; patched source
compiles cleanly into `nataraid.ko` on the guest.

## Threat model

Same as DF-1174: attacker supplies a disk with crafted RAID metadata; next
driver probe over-reads and panics. No privilege beyond disk-write capability.

Severity Medium: requires legacy `nata` (opt-in); not in GENERIC. High
(panic + small info leak) for systems that load `nata`/`nataraid`.