DF-2496 — divide-by-zero panics from crafted RAID geometry (nata ata-raid)

What was verified

sys/dev/disk/nata/ata-raid.c copies RAID geometry (interleave, width, total_sectors, heads/sectors) verbatim from on-disk metadata and uses the fields as divisors with no zero check. All three filed divide sites were driven to a deterministic kernel panic (fatal trap 18, integer divide fault) on the QEMU guest, each in its own boot:

Setup half (run_nonfatal.log, test 12): the production ata_raid_intel_read_meta() accepts crafted metadata with stripe_sectors=0 and total_sectors=0 and installs an AR_S_READY RAID0 array with interleave=0, total_sectors=0 — no parser validation.

Build / run (guest, root; requires vm.sh reset with-src)

cd /root/dfrig3 && ./build.sh     # KLD: production ata-raid.c #included verbatim
kldload ./dfrig3_ata.ko
sysctl kern.dfrig3_ata_test=12    # non-fatal: install degenerate geometry, print it
sysctl -n kern.dfrig3_ata_status
sysctl kern.dfrig3_ata_test=20    # FATAL: strategy divide (panic on serial)
# separate boots:
sysctl kern.dfrig3_ata_test=21    # arm REAL ata_raid_arrays[0], then:
/root/dfrig3/atastat 0            # FATAL: real ioctl hits status divide
sysctl kern.dfrig3_ata_test=22    # FATAL: attach divide

Expected (baseline): tests 20/21/22 each end in Fatal trap 18: integer divide fault while in kernel mode on the serial console (guest dead at db>).

Fix validation

fix.diff guards all sites (strategy RAID0/01/5 geometry check → biofinish(EIO), status->progress ternary, attach rounddown/ncylinders ternaries). Single-fix kernel built with nativekernel (see fix_build.log), rig rebuilt against the fixed source; fix_validation.log shows tests 20/21/22 all SURVIVING on the patched kernel: ar0: degenerate RAID0/01 geometry (interleave=0 width=2) + rig_bio_done b_error=5, attach completes, and the exact ioctl that panicked the baseline returns atastat: ok ... progress=0.

DF-2496 VERDICT — reproduced (all three divide sites panic the kernel)

Bottom line

CONFIRMED at every filed site. The nata RAID parsers copy geometry fields verbatim from on-disk metadata into the live struct ar_softc and the I/O / status / attach paths then use them as divisors with no zero check. On the audit guest (DragonFly 6.5-DEVELOPMENT x86_64, kernel #0 Thu Jul 2 2026), crafted Intel metadata (stripe_sectors=0, total_sectors=0) and a crafted JBOD geometry (heads=0) each produced a deterministic fatal trap 18 (integer divide fault), one per boot:

1. strategy (sys/dev/disk/nata/ata-raid.c:359): production ata_raid_intel_read_meta() (rig test 20) installs type=AR_T_RAID0, status=AR_S_READY, interleave=0; the production ata_raid_strategy() then executes chunk = blkno % rdp->interleave → Fatal trap 18 ... Stopped at ata_raid_strategy+0x2f3: divq %r12,%eax (panic_strategy.txt). The RAID5 variants (:366-372, /interleave, %(width-1), %width) are the same class and are covered by the same guard.
2. status via REAL kernel ioctl (ata-raid.c:1028): the rig's production parse (test 21) plants total_sectors=0 into the REAL kernel ata_raid_arrays[0] (0xffffffff8114dec0), and a real userland ioctl(IOCATARAIDSTATUS) on /dev/ata (atastat) executes the REAL built-in kernel's ata_raid_status divide → Fatal trap 18 ... Stopped at ata_raid_ioctl+0x11b: divq 0x48(%r14),%eax (panic_status_ioctl.txt; IP 0xffffffff803388eb is kernel-base built-in code, not the rig module). Full chain: userland syscall → /dev/ata → ioctl → attacker-zeroed divisor → fatal trap.
3. attach (ata-raid.c:181): crafted heads=0, sectors=63 on an AR_T_JBOD array (which also skips the rounddown(:157) variant) → production ata_raid_attach() divides by heads*sectors==0 → Fatal trap 18 ... divq inlined into the caller (panic_attach.txt).

Setup half: rig test 12 (run_nonfatal.log) shows the production Intel parse accepting stripe_sectors=0 AND total_sectors=0 and installing a READY RAID0 array — no parser-side validation exists.

Threat model

Attacker data is on-disk RAID metadata read at subdisk attach (boot or disk insertion on an nata ATA channel) — no OS privileges needed; the panic then triggers on the first I/O / status query / attach. On the standard guest the authentic boot-attach arm is blocked by the QEMU SeaBIOS/IDE-disk limitation documented in DF-2494, so the production parser+divide code is driven through the DF-2494 KLD rig (production ata-raid.c compiled in verbatim; only ata_queue_request is interposed to serve the crafted sector). The status site was additionally proven through the real kernel's own code and a real userland ioctl.

Fix validation (single-fix kernel)

fix.diff adds: strategy RAID0/01 guard (!interleave || !width) and RAID5 guard (!interleave || width < 2) with biofinish(EIO); status->progress ternary on total_sectors; attach ternaries for the rounddown divisor and heads && sectors. Kernel rebuilt (fix_build.log), rig rebuilt against the fixed source. fix_validation.log: tests 20/21/22 all survive — ar0: degenerate RAID0/01 geometry (interleave=0 width=2) + rig_bio_done b_error=5 (EIO) for strategy; attach completes (d_ncylinders=0); the previously-fatal ioctl returns atastat: ok type=4 ... progress=0. Baseline panics: 3/3; patched: 0/3.

Kernel references

• sys/dev/disk/nata/ata-raid.c:359-361 — RAID0/01 %interleave, /interleave, /width
• sys/dev/disk/nata/ata-raid.c:366-373 — RAID5 /interleave, %(width-1), %width
• sys/dev/disk/nata/ata-raid.c:1028 — 100 * rebuild_lba / total_sectors
• sys/dev/disk/nata/ata-raid.c:157-158 — rounddown(total_sectors, interleave*width)
• sys/dev/disk/nata/ata-raid.c:181 — total_sectors/(heads*sectors)
• sys/dev/disk/nata/ata-raid.c:2229,2231 — Intel parse copies stripe_sectors/total_sectors verbatim

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.