DF-2494 — ata_raid_lsiv2_read_meta() stores ar_softc* out of bounds past the global ata_raid_arrays[16] via untrusted on-disk raid_number (plus same-parse disks[disk_number] heap OOB)

File: sys/dev/disk/nata/ata-raid.c:2770-2884 · Severity: High · Bucket: memcorrupt · Confidence: certain Status: reproduced on the QEMU guest (production-code KLD rig, DF-5302/DF-5321/DF-5413 evidence class; the nata ata-bus subdisk attach path that feeds this parser is only reachable with an ATA disk on an nata controller, and the standard vm.sh QEMU guest cannot take an IDE hard disk at all — see VERDICT.md).

Build (guest, root)

cd /root/dfrig && ./build.sh     # compiles production ata-raid.c into dfrig_ata.ko

Run

sh run.sh                        # rig tests 1, 2, 4 (survivable proofs)
sysctl kern.dfrig_ata_test=5     # +2040 store then configs[255] OOB read (serial log)
sysctl kern.dfrig_ata_test=6     # REAL kernel ata_raid_arrays target (boot-attack arm)

Expected (see run.log)

• test 1: production parse stores 0xfffff80116973700 at raidp[29] — 104 bytes past the 128-byte ata_raid_arrays[16]; parse returns 1 (array accepted).
• test 2: first OOB slot raidp[16] (= &atapi_cam_devclass in the real kernel) written and retained.
• test 4: same parse writes raid->disks[49] 40 bytes past the 2424-byte struct ar_softc allocation (dev pointer, flags=0xb).
• test 6: with raidp = the REAL kernel ata_raid_arrays (0xffffffff8114dec0), the production skip-occupied walk plants/uses pointers in real kernel BSS and heap past the array — cross-subsystem corruption, silent.

Fix

fix.diff (shared shape with the DF-2495 pack): validate meta->raid_number < MAX_ARRAYS and meta->disk_number < MAX_DISKS in ata_raid_lsiv2_read_meta(). Validated on a rebuilt kernel (fix_build.log / fix_run.log).

DF-2494 VERDICT — reproduced (production-code rig; real-kernel BSS target)

Bottom line

The pass-1 claim is real and worse than filed: ata_raid_lsiv2_read_meta() (sys/dev/disk/nata/ata-raid.c:2799-2879) indexes the caller's raidp[] (production callers pass the 16-entry global ata_raid_arrays, ata-raid.c:138/1477) at array + meta->raid_number where meta->raid_number is a raw u_int8_t taken from the last sector of the disk (LSIV2_LBA, ata-raid.h:456-457). There is no bound check anywhere on the path. On the guest this was proven three ways, all through 100% production parser code (the only interposed seam is ata_queue_request, which completes the metadata READ the way the disk would):

1. rig test 1 (deterministic) — raid_number=29: the production parser kmalloc()d an ar_softc and stored the pointer at raidp[0+29], 104 bytes past the end of the 16-entry array; parse returned 1 (array accepted).
2. rig test 2 (deterministic) — raid_number=16: the store landed on the FIRST byte past the array (offset +128). In the real guest kernel that exact address is &atapi_cam_devclass (nm: ata_raid_arrays=0xffffffff8114dec0, atapi_cam_devclass=0xffffffff8114df40). With an accepted RAID type the pointer is RETAINED (only the unknown-RAID-type cleanup path at 2849-2850 frees/nulls it).
3. rig test 6 (real-kernel arm) — with raidp pointed at the REAL kernel ata_raid_arrays (0xffffffff8114dec0), the production skip-occupied walk (2802-2814: an occupied slot whose object's format/magic_0 fields do not look like a fresh array → continue) walked across the real BSS neighbors (atapi_cam_devclass, acd_/afd_/ast_devclass all occupied) and: - run A (raid_number=23): the target slot raidp[23] = &sysctl__hw_amr_children was occupied (it legitimately points at the hw.amr.force_sg32 oid), so the walk continued to raidp[24]/raidp[25] and the array landed there — real kernel BSS 192+ bytes past the array. - run B (raid_number=16): the first slot whose pointed-to heap object happened to pass the format/magic_0 checks (raidp[20], +160) got the parse's field writes into that unrelated live heap object (cross- subsystem type-confusion write: magic_0=timestamp, type, total_disks, format, disks[2].dev/.sectors/.flags). rc=1, guest stayed up — silent corruption of an unknown victim allocation.

Corroboration in the same parse function: meta->disk_number (u_int8_t) is used unvalidated at raid->disks[meta->disk_number] (2866-2876) and meta->configs[raid_number] is read with raid_number up to 255 against the 30-entry table (2819-2822). rig test 4 (disk_number=49) showed the disks[49] writes landing 40 bytes past the 2424-byte ar_softc allocation (readback dev=<parent ptr> flags=0xb); rig test 5 (raid_number=255) showed the +2040 store followed by the configs[255] OOB read ~3.5 KB past the 512-byte metadata object (in that run the garbage type=0 took the unknown-type cleanup path: pointer freed, OOB slot re-nulled — a transient write; the persistent-corruption range is raid_number in [16..29], and for raid_number >= 30 persistence depends on adjacent-heap garbage).

Threat model reality check

• The trigger is on-disk crafted metadata read at subdisk attach (boot or disk insertion on an nata-controlled ATA channel). No privileges needed in the OS — the DF-5339-style crafted-disk model.
• The authentic boot arm could not be armed on the standard guest: attaching ANY IDE hard disk (even a benign unrelated image, tried usbstick.img) to the vm.sh QEMU invocation hangs SeaBIOS before the loader produces a single serial byte (CPU observed HLT'd/spinning in the BIOS). This is an infrastructure limitation of the standard snapshot, not a property of the bug; the rig arm above drives the same production parser against the same real kernel BSS target instead.
• Practical primitive: an 8-byte kernel-heap-pointer plant at attacker-chosen offset +128..+2040 past ata_raid_arrays (skip-occupied semantics), or — when the landed slot already holds a heap pointer whose object passes the format/magic checks — silent field writes into that live object (type confusion). Deterministic panic was not achieved on this guest (the obvious victim, sysctl__hw_amr_children, happens to be occupied at boot, and curfail.19623's object survived the field writes).

Fix validation

fix.diff adds, right after the $XIDE$ magic check: if (meta->raid_number >= MAX_ARRAYS || meta->disk_number >= MAX_DISKS) goto lsiv2_out; This simultaneously bounds raidp[array + raid_number] (array < 16), meta->configs[raid_number] (< 30), and — with the companion disk_count check — raid->disks[...]. Validated on a single-fix rebuilt kernel (fix_build.log / fix_run.log): rig tests 1/2 return rc=0 with the witness slots untouched, and the real-kernel test 6 leaves the real BSS neighbors unchanged.

Kernel references

• sys/dev/disk/nata/ata-raid.c:2799-2806 — raidp[array + meta->raid_number] OOB store
• sys/dev/disk/nata/ata-raid.c:2816 — array += meta->raid_number loop-counter corruption
• sys/dev/disk/nata/ata-raid.c:2819-2822 — meta->configs[raid_number] OOB read (table is [30])
• sys/dev/disk/nata/ata-raid.c:2866-2876 — raid->disks[meta->disk_number] OOB write
• sys/dev/disk/nata/ata-raid.h:456-513 — LSIV2_LBA, struct lsiv2_raid_conf (raid_number/disk_number u_int8_t)
• sys/dev/disk/nata/ata-raid.c:138 — static struct ar_softc *ata_raid_arrays[MAX_ARRAYS]

Fix status (batch validation)

Applied with the 36 sibling fix.diffs of this batch in findings/poc/_batch41/all_fixes.patch; single in-guest make -j6 nativekernel KERNCONF=X86_64_GENERIC completed RC=0 with zero errors under -Werror (full log: findings/poc/_batch41/fix_build8.log). Behavior A/B intentionally skipped for this Info-tier item.