Summary

ahci_pm_read and ahci_pm_write call ahci_ata_get_xfer() and immediately dereference the returned xa without a NULL check. ahci_ata_get_xfer returns NULL when the per-port CCB free pool is empty (ahci.c:3675-3678). The pool has sc_ncmds-1 slots available to CAM (ahci_cam.c:113 reserves one for error recovery) and can be exhausted by in-flight NCQ commands. ahci_pm_check_good invokes ahci_pm_read then ahci_pm_write unconditionally at ahci_pm.c:917,922, and it is called from the port-multiplier hot-plug state machine (ahci.c:891 and ahci.c:841) before ahci_beg_exclusive_access drains in-flight commands — so a hot-plug / async-notify event arriving during heavy I/O to any disk behind the PM crashes the kernel.

Root cause

ahci_pm_read at sys/dev/disk/ahci/ahci_pm.c:976 does:

xa = ahci_ata_get_xfer(ap, ap->ap_ata[15]);
xa->fis->type = ATA_FIS_TYPE_H2D;   /* line 978 — deref without NULL check */

ahci_pm_write has the identical pattern at lines 1013/1015.

ahci_ata_get_xfer (sys/dev/disk/ahci/ahci.c:3669-3689) explicitly returns NULL when ahci_get_ccb finds the free pool empty (TAILQ_FIRST(&ap->ap_ccb_free) is NULL).

The CCB pool is sized sc_ncmds (≥4, ahci_attach.c:349) with slot 1 reserved as ap_err_ccb (ahci.c:436-437), leaving sc_ncmds-1 slots that CAM is permitted to fill (ahci_cam.c:112-113).

The dangerous caller is ahci_pm_check_good (ahci_pm.c:908), which is reached from ahci_port_state_machine at ahci.c:841 (top-level ahci_pm_read(ap, 15, SATA_PMREG_EINFO, &data)) and ahci.c:891 (ahci_pm_check_good(ap, target)) — both invoked while only the port lock is held, BEFORE the ahci_beg_exclusive_access(ap, at) call at ahci.c:938 that would drain ap_active/ap_sactive.

Contrast with ahci_get_err_ccb (ahci.c:3331) which uses the reserved slot-1 CCB and cannot fail — PM register access has no equivalent reservation.

Threat model

Attacker position: local user with read/write access to any disk sitting behind a SATA port multiplier on the target HBA, OR a malicious PM / malicious drive firmware (evil-peripheral model).

Preconditions:

1. ap_type == ATA_PORT_T_PM (a PM is attached)
2. The CCB free pool is drained — trivially achieved by flooding the disk behind the PM with NCQ commands (e.g. asynchronous O_DIRECT AIO, or multiple threads issuing READ DMA EXT)
3. The PM asserts an async-notify / hot-plug bit (a real hot-plug on any port, or a malicious PM spamming SDB FIS notify, or spurious PhyRdy changes from a flaky link)

The kernel thread running ahci_port_state_machine then calls ahci_pm_check_good, which calls ahci_pm_read/ahci_pm_write, which dereference NULL → page fault on VA 0 → kernel panic.

Impact: system-wide denial of service (panic + reboot); no privilege escalation because page 0 is unmapped in the kernel address space, so the deref faults before any attacker-controlled write can occur.

Requires either physical access (to yank/replug a cable) or compromised PM firmware; cannot be triggered purely from an unprivileged process without the PM/hot-plug precondition.

PoC

findings/poc/DF-1659/:

Hardware path (most reliable):

1. Attach a 5-bay SATA port multiplier to an AHCI port.
2. Plug a disk into PM port 0.
3. From an unprivileged account with access to the resulting /dev/daX, run fio --name=flood --filename=/dev/daX --ioengine=aio --iodepth=32 --rw=randread --bs=4k --numjobs=4 --direct=1 --time_based --runtime=300 (or an equivalent pthreaded AIO loop issuing ≥ sc_ncmds-1 in-flight reads) to saturate the CCB free pool.
4. While the flood is running, hot-plug or hot-unplug a second disk into PM port 1 (or have a malicious PM emit spurious async-notify bits).

Within a few attempts the kernel thread servicing the port will panic with a NULL deref inside ahci_pm_read/ahci_pm_write.

Build: cc -O2 -o flood flood.c -lpthread where flood.c is a pthreaded AIO loop on /dev/daX.

Success criterion: dmesg shows:

Fatal trap 12: page fault while in kernel mode
fault virtual address = 0x0
...
ahci_pm_read+0x... or ahci_pm_write+0x...
ahci_pm_check_good+0x...
ahci_port_state_machine+0x...

Software-only path is much harder because the attacker must also coerce the HBA into asserting a hot-plug notification without physically toggling the link; a malicious PM (e.g. a reprogrammable Cypress/Renesas PM, chipid 0x37261095) can emit SDB FIS notify bits on demand via PMREG_FEAEN + SATA_PMFEA_ASYNCNOTIFY (ahci_pm.c:498-512) to trip the state machine at will.

Recommended fix

Defensive NULL check after ahci_ata_get_xfer in both PM register helpers. This matches the contract of ahci_ata_get_xfer (which is documented to return NULL) and is the same shape used elsewhere when failure is tolerable. The err: return semantics are preserved (EIO to callers, which already handle it).

--- a/sys/dev/disk/ahci/ahci_pm.c
+++ b/sys/dev/disk/ahci/ahci_pm.c
@@ -973,6 +973,10 @@ ahci_pm_read(struct ahci_port *ap, int target, int which, u_int32_t *datap)
 {
    struct ata_xfer *xa;
    int error;

    xa = ahci_ata_get_xfer(ap, ap->ap_ata[15]);
+   if (xa == NULL) {
+       *datap = 0;
+       return (EIO);
+   }

    xa->fis->type = ATA_FIS_TYPE_H2D;
    xa->fis->flags = ATA_H2D_FLAGS_CMD | 15;
--- a/sys/dev/disk/ahci/ahci_pm.c
+++ b/sys/dev/disk/ahci/ahci_pm.c
@@ -1010,6 +1010,9 @@ ahci_pm_write(struct ahci_port *ap, int target, int which, u_int32_t data)
 {
    struct ata_xfer *xa;
    int error;

    xa = ahci_ata_get_xfer(ap, ap->ap_ata[15]);
+   if (xa == NULL)
+       return (EIO);

    xa->fis->type = ATA_FIS_TYPE_H2D;
    xa->fis->flags = ATA_H2D_FLAGS_CMD | 15;

A more thorough fix would also reserve a dedicated PM-register CCB at ahci_port_alloc time (mirroring ap_err_ccb at ahci.c:436-437) so PM register access can never block on the regular free pool; the simple NULL check above is the minimum to convert the panic into a graceful EIO that the state machine already tolerates.