DF-2423 — NULL deref in ahci_pm_read/ahci_pm_write when the per-port CCB pool is exhausted

What was verified and how

sys/dev/disk/ahci/ahci_pm.c:976-978 (ahci_pm_read) and :1013-1015 (ahci_pm_write) call ahci_ata_get_xfer() and immediately dereference the result through xa->fis with no NULL check. ahci_ata_get_xfer (sys/dev/disk/ahci/ahci.c:3669-3689) returns NULL whenever ahci_get_ccb() (ahci.c:3297) finds the per-port free list ap->ap_ccb_free empty — i.e. all sc_ncmds (AHCI_REG_CAP_NCS, up to 32, ahci_attach.c:349, pool alloc ahci.c:370) command slots of the port are in flight. struct ata_xfer.fis is the FIRST member of the struct (atascsi.h:356-358), so the unchecked load xa->fis faults at VA 0x0.

Rig: verbatim-interposition, kernel-compiled harness (dfx2423.c in this pack). The PRISTINE ahci_pm.c TU (sha256 db2f57847144879bb89c13869476e95c643ff832be6c7f13ea963ba0f2bbac66, gate enforced by build.sh) is #included into a harness file compiled into a custom DFX2423 kernel. Because the stock X86_64_GENERIC config builds the ahci driver into the kernel (config:65 device ahci), every symbol the TU defines is renamed ahci_pm_* -> dfx_pm_* via preprocessor defines — the function bodies compile byte-verbatim (proven by the panic IPs matching the disassembly of the renamed symbols). Only the three pool-path functions are interposed onto fabrications:

• dfx_ahci_ata_get_xfer — faithfully models ahci.c:3674-3688 (NULL on exhausted pool, otherwise the same bzero/at/fis preset);
• dfx_ahci_ata_cmd — fabricated completing device (fills rfis, sets ATA_S_COMPLETE, invokes the REAL static ahci_pm_dummy_done hook that the verbatim code assigns to xa->complete);
• dfx_ahci_ata_put_xfer — models ahci_put_ccb (ahci.c:3317-3330).

All other TU externals (ahci_pread, ahci_poll, ...) link against the REAL in-kernel ahci driver. Trigger: sysctl hw.dfx2423_phase=N (1=control, 2=exhausted read, 3=exhausted write).

Results

Machine-code A/B in disas.baseline-vs-fixed.txt: baseline has no check between callq dfx_ahci_ata_get_xfer and mov (%rax),%rdx; the fixed kernel inserts test %rax,%rax; je before the deref.

(Nit: the expectation comment inside dfx2423.c says flags=9f; the correct arithmetic is ATA_H2D_FLAGS_CMD|15 = 0x80|0x0F = 0x8f, which is what the code actually produced in every run. The comment slip is left as-built so the shipped source hash 8c3f8d92...d38e matches the compiled artifact.)

Why the NULL actually happens in production (reachability)

The per-port CCB pool is shared by ALL targets behind a port multiplier on that HBA port. The PM state machine ahci_port_state_machine (ahci.c:796) runs:

• on boot/attach and after PM events from the per-port kernel thread (ahci_port_thread_core, ahci.c:2525), and
• from CAM rescan context (ahci_cam.c:889 XPT_ENG_EXEC, ahci_cam.c:922 XPT_PATH_INQ wildcard) — the XPT/queue path being a kernel thread or a privileged caller (/dev/xpt0 is crw------- root:operator).

At ahci.c:841 it calls ahci_pm_read(ap, 15, SATA_PMREG_EINFO, &data) without holding exclusive access — ahci_beg_exclusive_access is only taken later for the probe steps (ahci.c:~950). Likewise ahci_pm_check_good (called at ahci.c:891 before exclusive access) issues pm_read/pm_write at ahci_pm.c:917/922/943. So while CAM keeps all 32 slots busy with NCQ I/O on other PM targets, an async-notify event (PM hot-plug bitmap, D2H/SDB notify FIS — a hostile or merely flaky port multiplier can generate these at will) walks straight into the NULL deref. The probe-time callers (ahci_pm_identify etc.) run with the port stopped/quiesced, so the state-machine/hotplug path is the realistic one. Race window is real but needs: AHCI HBA with CAP.SPM, a port multiplier attached, async-notify enabled (CAP.SSNTF + PM feature, ahci_pm.c:498-513), all CCBs in flight, and a notify event landing in that window — hence Medium severity, hardware-gated local DoS.

Privesc assessment (explicit close)

The fault is a fixed-offset (0x0) supervisor-mode LOAD whose page is guaranteed not-present in the contexts the real driver runs in (kernel threads use the kernel map; user mappings are not visible). The faulting value and every subsequent store target (fis->... constants, which/data bytes) are therefore never attacker-controlled on the real path: deterministic panic → DoS only, no privilege escalation.

One nuance documented for completeness: DragonFly does allow mmap(MAP_FIXED, NULL) in user processes (verified on the guest: /tmp/nullmap mapped page 0 read/write — see env.txt note), so IF a future code path executed ahci_pm_read in an unprivileged user vmm-context, the NULL load would fetch an attacker-chosen pointer and the following FIS stores would become semi-controlled arbitrary-address writes. No such unprivileged path exists today — the only user-context entries (XPT_PATH_INQ/XPT_ENG_EXEC via /dev/xpt0, /dev/passN) are 0600 root:operator, i.e. already-privileged. The applied fix removes the entire question. Related observation (out of scope for this finding): the same unchecked ahci_ata_get_xfer idiom exists at ahci_cam.c:300, :387, :539, :562, :589, :693, :1082, :1524 and ahci.c:4057, :4090 — those run in attach/exclusive contexts today but deserve the same guard.

Fix

fix.diff in this pack (validated A/B above): NULL-check with graceful return (EBUSY) in both ahci_pm_read and ahci_pm_write, matching the DPRINTF the allocator itself anticipates (ahci.c:3676). Callers already treat non-zero as transient failure (state machine retries on the next notify event; check_good prints and moves on).

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.