DF-2210 — PoC evidence pack (verify run, 2026-10-17)

Finding: sys/dev/disk/nata/chipsets/ata-national.c:77-78 — ata_national_setmode() unconditionally executes

    ch->dma->alignment = 16;            /* ata-national.c:77 */
    ch->dma->max_iosize = 64 * DEV_BSIZE;   /* ata-national.c:78 */

with no NULL guard. Its own template (the Cyrix twin this chip is a clone of, chipsets/ata-cyrix.c:82-101) guards the identical derefs behind if (ctlr->r_res1). ch->dma is legitimately NULL in production: ata-dma.c:151-154 frees ch->dma and NULLs it whenever DMA allocation fails ("WARNING - DMA allocation failed, disabling DMA"), after which the channel keeps running PIO-only — and every later setmode funnel (boot reinit, IOCATASMODE ioctl ata-all.c:523-526, acd_open atapi-cd.c:147/226) panics the kernel with a NULL-page WRITE instead of setting PIO mode.

How it was verified (production-handler KLD dispatch rig)

Hardware is gated (National Geode SC1100, PCI ID 0x0502100b), so the established rig class was used (dfrig_nat.c — same class as DF-252x trm / DF-249x nata):

• the production chipsets/ata-national.c is #included verbatim into the KLD (build.sh pins sha256 c694b9095ed2dc50acb932a2ecde564b535c5a0f66cba355a0345d69b16a43e6 = the audited sys/ tree; the only textual intervention renames the never-called ata_national_ident to avoid a duplicate global with the built-in kernel copy — ata_national_setmode itself is compiled byte-for-byte under its production name);
• the running kernel's own ata_national_setmode (local symbol, nm /boot/kernel/kernel → 0xffffffff80321780 on the stock kernel) is dispatched by address — the shipped binary, zero recompilation;
• the fabricated state is exactly what the machine presents when DMA is unavailable: ch->dma == NULL, disk present (ch->devices = ATA_ATA_MASTER), PIO4/UDMA2-capable identify data; the channel is in the ATA_STALL_QUEUE state with a hw.begin_transaction that reports the drive accepting SETXFER, so the kernel's own production ata_controlcmd()/ata_queue_request() run unmodified (synchronous CONTROL completion, ata-queue.c:100-115); PCI config timing writes dispatch through the real kernel kobj machinery onto a recording fake bus;
• dispatch is either direct or through the extracted real call site (ata_pcichannel_setmode, ata-pci.c:855-866).

Scenarios (sysctl kern.dfrig_nat.go=N)

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

cd /root/dfrig_nat && sh build.sh     # KLD with verbatim production file
kldload ./dfrig_nat.ko
KADDR=$(nm /boot/kernel/kernel | awk '/ t ata_national_setmode$/{print $1}')
sysctl -w kern.dfrig_nat.addr=0x$KADDR
sysctl -w kern.dfrig_nat.go=2         # CONTROL first (returns)
sysctl -w kern.dfrig_nat.go=1         # THE FINDING — panics a stock kernel

Expected on a stock kernel: Fatal trap 12: page fault while in kernel mode, fault virtual address = 0x58, supervisor write data, page not present, Stopped at ata_national_setmode+0x65: movl $0x10,0x58(%rax) — the store of the constant 16 (0x10) to offsetof(struct ata_dma, alignment) (0x58) through the NULL ch->dma — and the guest dead at db>.

Fix validation

fix.diff guards the two stores with if (ch->dma) { ... } (the canonical guard the Cyrix twin already carries). Single-fix kernel built with make -j6 nativekernel KERNCONF=X86_64_GENERIC (fix_build.log); the exact same rig re-run against the patched kernel (fix_run.log): go=1/go=3/go=5 RETURN — setmode completes in PIO (mode set, PCI timings written, no panic) — and the go=2/4/6 controls behave identically to stock (dma fields still overridden when dma exists).

Artifacts

• dfrig_nat.c / Makefile / build.sh / run.sh — the rig
• build.log — full untrimmed baseline build (checker sha lines included)
• run_control.log — controls go=2/4/6 on stock kernel (dma exists)
• panic.txt — serial console: go=1, kernel's own handler, dma=NULL
• panic_rig_copy.txt — serial console: go=3, verbatim copy, dma=NULL
• kernel_handler_disasm.txt — objdump of the stock kernel handler (+0x65 = line 77 store; next store +0x73 = line 78)
• fix.diff — git-apply-able guard
• fix_build.log / fix_run.log — patched-kernel build + validation run
• env.txt — guest environment
• VERDICT.md — full narrative
• manifest.json / verdict.json — machine-readable verdicts

DF-2210 — VERDICT

Finding: sys/dev/disk/nata/chipsets/ata-national.c:77-78 — ata_national_setmode() dereferences ch->dma (->alignment, ->max_iosize) unconditionally; NULL ch->dma (DMA allocation failed, ata-dma.c:151-154, or busmastering unavailable) turns every later setmode into a kernel NULL-page WRITE → panic. Medium / local DoS.

Verdict: REPRODUCED (panic), then FIX VALIDATED.

1. Root cause confirmed in source

• chipsets/ata-national.c:77-78 stores through ch->dma with no guard, before even issuing SETXFER.
• The Cyrix twin (chipsets/ata-cyrix.c:82-101) — the SC1100 is a documented Cyrix clone, see the ident comment at ata-national.c:44 — guards the same derefs behind if (ctlr->r_res1) { ch->dma->alignment = 16; ... }.
• ch->dma is NULL-able in production: ata-dma.c:151-154 (ata_dmaalloc error path) prints "WARNING - DMA allocation failed, disabling DMA", frees ch->dma and sets it to NULL; the channel continues PIO-only.
• Every setmode funnel reaches the handler:
• boot/reinit: ata_pcichannel_setmode (ata-pci.c:855-866) calls ctlr->setmode(dev, ATA_PIO_MAX);
• ioctl: IOCATASMODE (ata-all.c:523-526) → ATA_SETMODE newbus method (ata_if.m) → same ata_pcichannel_setmode;
• device open: acd_open (atapi-cd.c:147), atapi-tape.c:121, atapi-fd.c:107, ata-disk.c:436 — all call ATA_SETMODE.

2. Rig (hardware-gated → production-handler KLD dispatch class)

The SC1100 chipset is absent under QEMU, so per the established rig class (DF-252x trm, DF-249x nata) dfrig_nat.c:

• #includes the production chipsets/ata-national.c verbatim (build.baseline.log checker: guest file sha256 c694b9095ed2dc50acb932a2ecde564b535c5a0f66cba355a0345d69b16a43e6 == audited sys/ tree). Only the never-called ata_national_ident is renamed (duplicate global vs the built-in kernel copy); ata_national_setmode compiles byte-for-byte under its own name.
• ALSO dispatches the running kernel's own handler by address (nm /boot/kernel/kernel → t ata_national_setmode = 0xffffffff80321780 stock) — the shipped binary, no recompile.
• Fabricates exactly the DMA-unavailable machine state: ch->dma = NULL, disk present (ch->devices = ATA_ATA_MASTER), PIO4/UDMA2 identify params, channel in ATA_STALL_QUEUE state with a hw.begin_transaction answering SETXFER-accepted, so the kernel's real ata_controlcmd()/ata_queue_request() (ata-queue.c:158-190, synchronous CONTROL completion at ata-queue.c:100-115) run unmodified; PCI config writes dispatch through the real kobj machinery onto a recording fake bus.
• Dispatches direct or through the extracted real call site (ata_pcichannel_setmode, ata-pci.c:855-866).

3. Baseline result (stock kernel, INVARIANTS): panic at :77, twice

go=2/4/6 controls (dma exists) first proved the scaffolding faithful: alignment 2→16, max_iosize 65536→32768, real ata_controlcmd dispatch (1 SETXFER), PCI writes 0x44←0x80000000, 0x40←0x00100010 (= piotiming[4]), and for the UDMA2 request 0x44←0x80911030 (= udmatiming[2]), atadev->mode=0x42 — the production timing tables to the last digit (run_control.log).

Then the DMA-unavailable dispatches:

dfrig_nat[go1]: BEFORE dispatch: ch->dma=0 (NULL means DMA unavailable, ata-dma.c:153)
dfrig_nat[go1]: dispatching production ata_national_setmode(dev, ATA_PIO_MAX) (RUNNING KERNEL own copy)
Fatal trap 12: page fault while in kernel mode
fault virtual address  = 0x58
fault code             = supervisor write data, page not present
instruction pointer    = 0x8:0xffffffff803217e5
Stopped at  ata_national_setmode+0x65:  movl $0x10,0x58(%rax)

(panic.txt; guest dead at db>, ssh gone, vm.sh status = down.)

Instruction↔line attribution is airtight (kernel_handler_disasm.txt):

ffffffff803217de: mov 0x1d8(%r15),%rax      ; rax = ch->dma (NULL)
ffffffff803217e5: movl $0x10,0x58(%rax)     ; LINE 77  alignment=16   <-- faults
ffffffff803217ec: mov 0x1d8(%r15),%rax      ; reload ch->dma
ffffffff803217f3: movl $0x8000,0x64(%rax)   ; LINE 78  max_iosize=64*DEV_BSIZE

IP 0xffffffff803217e5 is ata_national_setmode+0x65, the store of the constant 16 (0x10) to offset 0x58 — exactly the line-77 store through the NULL ch->dma; vad 0x58 = offsetof(struct ata_dma, alignment); "supervisor write". The panic repeats identically for the verbatim #included copy (panic_rig_copy.txt, go=3: same vad 0x58, same ata_national_setmode+0x65: movl $0x10,0x58(%rax)), proving the rig-compiled code is behaviorally identical to the shipped binary.

Impact: NULL-page write of fully controlled constants (16 / 32768) at fixed offsets 0x58/0x64 — not mappable on amd64 (page 0 is hard-wired unmappable), so the primitive is a deterministic local kernel panic / reboot-candidate (DoS), not an escalation. No route to uid=0.

4. Fix validation (single-fix kernel)

fix.diff guards the two stores:

    if (ch->dma) {
    ch->dma->alignment = 16;
    ch->dma->max_iosize = 64 * DEV_BSIZE;
    }

— the same protection the Cyrix original already carries (ata-cyrix.c:82), applied to the National code path that has no r_res1 resource (its register access is PCI config of the grandparent, which stays valid; only the ch->dma writes needed the guard).

Rebuilt with make -j6 nativekernel + installkernel (fix_build.log, kernel #1: Sat Oct 17 08:46:06 UTC 2026, sha256 d578088322657bb02e15787837bad2582c89869a8cf55af1f7c5208c1795a075), rebooted, rig rebuilt from the patched source (checker notes the new sha 6efe3d30...), and the exact same scenarios re-run (fix_run.log):

Patched-kernel disassembly (fixed_handler_disasm.txt) shows the guard in the binary: mov 0x1d8(%r15),%rax; test %rax,%rax; je +0x74 skipping both stores.

Baseline reproduced = 1 (twice), patched reproduced = 0. Fix status: fixed.

5. Honesty notes / limitations

• The PCI ID gate means the shipped binary path cannot attach on this guest; the rig dispatches the shipped handler directly with the post-attach state. All code paths exercised are production bytes; the only fabrications are the device graph, the SETXFER answer, and the PCI config backing store — none of which sit between the cited deref and its NULL input.
• The panic occurs in sysctl write context on the rig; on real hardware the identical fault fires from the boot reinit / ioctl / open funnels cited above (all reach the same first call with mode=ATA_PIO_MAX).
• Not a privilege escalation: constant-only NULL-page write (page 0 unmappable on amd64). Classified panic/DoS.

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.