DF-3772 — KKASSERT on hardware-fed CI/SACT consistency panics on chipset misbehavior the driver itself anticipates

File: sys/dev/disk/ahci/ahci.c (pass 2, GLM 5.3)

What the bug is

ahci_port_intr() opens every invocation with:

ci_saved = ahci_pread(ap, AHCI_PREG_SACT or AHCI_PREG_CI);   /* ahci.c:2615/2618 */
KKASSERT(!(ap->ap_sactive && ap->ap_active));                /* ahci.c:2621 */
KKASSERT((ci_saved & (ap->ap_sactive | ap->ap_active)) == ci_saved); /* ahci.c:2622 */

The second assertion requires the hardware CI/SACT register to be a subset of the driver's software masks. DragonFly's own comments document that real chipsets violate exactly this invariant:

• ahci.c:3117-3123: "If we are stopped the AHCI chipset is supposed to have cleared CI and SACT. Did it? If it didn't we try very hard to clear the fields… IFS errors on (at least) AMD chipsets create this confusion."
• ahci.c:3933-3948 (timeout path): detects ahci_pactive() != 0 after a stop, prods the chip, and on failure only prints "chipset failed to clear active cmds" — i.e. the driver is designed to survive stale CI/SACT bits.
• ahci.h:1117-1122 (port_stop warning): stale CI/SACT races are expected.

But the recovery code at ahci.c:3125-3139 runs after the assert. Concrete panic sequence (no other bug needed):

1. A command times out; ahci_ata_cmd_timeout() (ahci.c:3892) stops the port.
2. An affected chipset leaves the slot's CI bit set (the documented AMD-IFS behavior).
3. Timeout processing clears the software mask (ahci.c:3902/3905), restarts the port (3930), notices ahci_pactive() != 0 (3940), prods, gives up with a kprintf (3943-3947).
4. The very next ahci_port_intr() (invoked by the timeout path itself at ahci.c:3951) re-reads CI with the stale bit set while the software mask no longer has it → KKASSERT at ahci.c:2622 fails → kernel panic.

Related asserts with the same trust model on the same error paths: - ahci_get_err_ccb(): KKASSERT(ci == 0) (ahci.c:3351) on the hardware CI register read at 3346 — violated by the same stale-CI condition. - ahci_put_err_ccb(): unconditional panic("…but CI %08x != 0") (ahci.c:3398-3403).

Impact: a device/chipset error condition that the driver is otherwise able to recover from converts into a guaranteed kernel panic — denial of service. Same attacker model as DF-1210/DF-1211 (device-fed registers), but impact is panic, not OOB memory access → Low.

Why not reproduced on the guest

No AHCI controller on the audit guest (see env.txt). The assert is only reachable through a real AHCI interrupt/error path. Source-level reasoning is line-accurate; verdict not_reproduced (device absent).

Reproduce on suitable hardware

Any AHCI chipset known to leave CI/SACT dirty across a port stop during IFS error recovery (driver comments call out AMD 880G/SB850-class parts), plus a command timeout (hung/errored device). Alternatively a QEMU ich9-ahci regression test that deasserts CI improperly.

DF-3772 VERDICT — not_reproduced (no AHCI hardware on guest); panic path certain by source

Bottom line

ahci_port_intr() asserts that the hardware-fed CI/SACT register snapshot is a subset of the driver's software slot masks (ahci.c:2621-2622). The driver's own comments and recovery code (ahci.c:3117-3139, 3933-3948) document that real chipsets — specifically AMD parts after IFS errors — leave stale CI/SACT bits after a port stop, and the driver is written to survive that condition. The KKASSERT runs before any of that recovery on every interrupt, so the documented misbehavior is turned into a guaranteed panic() instead of the intended recovery. The same pattern exists as KKASSERT(ci == 0) on a hardware read in ahci_get_err_ccb() (ahci.c:3346-3351) and as an explicit panic("…but CI %08x != 0") in ahci_put_err_ccb() (ahci.c:3397-3403).

Chain (why the assert fires despite the "recovery")

• ahci.c:3890-3907 — timeout: read CI/SACT, stop port, clear software masks for expired slots.
• ahci.c:3930 — restart port.
• ahci.c:3940-3948 — detect stale hardware bits (ahci_pactive() != 0), prod, then give up with a warning only ("what do we do now?" — ahci.c:3137).
• ahci.c:3951 — call ahci_port_intr(ap, 0); at ahci.c:2615/2618 the stale bits are read into ci_saved; software masks were cleared at 3902/3905; KKASSERT at 2622 fails → panic.

No memory corruption — the subsequent walks are properly masked by software bits (checked: ahci.c:3080 ci_masked = ci_saved & *active & ~ap->ap_expired, ahci.c:3152 ci_masked = ~ci_saved & *active). The defect is purely the assert's contradiction with the driver's own hardware-behavior assumptions. CWE-617 (reachable assertion) → DoS only → Low.

Not-reproduced rationale

The guest has zero AHCI hardware (env.txt: pciconf empty, virtio-blk root, ahci static in GENERIC). The assert lives on the AHCI interrupt path and cannot be entered. No amount of guest setup short of a different QEMU machine config (vm.sh is fixed to virtio-blk) can instantiate it.

Recommended fix

Replace the hardware-subset KKASSERT at ahci.c:2622 with mask-and-warn (keep the software-only invariant assert at 2621), downgrade ahci_get_err_ccb()'s KKASSERT (ahci.c:3351) to a warning + CI register clear, and replace ahci_put_err_ccb()'s panic() (ahci.c:3398) with a kprintf + register clear. fix.diff generated from a scratch worktree and verified to apply cleanly against the pristine tree.

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.