DF-4369 — hpt27xx: hpt_timeout / os_cmddone completion race → use-after-free of PCOMMAND

What this is

A pass-2 (GLM 5.3) audit finding in sys/dev/raid/hpt27xx/hpt27xx_osm_bsd.c: the per-command timeout hpt_timeout() races the completion path os_cmddone(). os_cmddone() uses callout_stop(), which on DragonFly explicitly does not interlock against an in-progress callout, and then frees the command (ldm_free_cmds(pCmd)) and its extension. If the 20-second timeout fires on another CPU at the same instant the command completes, hpt_timeout() dereferences pCmd->priv after the free — a use-after-free read that becomes a wild-pointer dereference when the freed PCOMMAND is immediately recycled (e.g. as a flush command whose priv points at a kernel stack variable).

Build / Run / Expected

This bug is hardware-gated: it requires a HighPoint RocketRAID 27xx SAS controller (PCI vendor 0x1103) attached and processing I/O.

• There is nothing to build on the audit guest: the driver is already compiled into its X86_64_GENERIC kernel (sys/config/X86_64_GENERIC:117).
• ./run.sh (or bash verify_env.sh) probes the guest and prints: kernel/uname, the full PCI device list, and the hpt27xx module state.
• Expected on real hardware (not available here): under SMP with I/O that completes in the same instant its HPT_OSM_TIMEOUT (20 s) deadline expires, hpt_timeout() reads pCmd->priv of a command already released to the LDM freelist; if the command block was recycled (flush: priv = &done kernel stack at hpt27xx_osm_bsd.c:303; internal ldm commands: priv per blob), ext->vbus_ext resolves to a stack/garbage pointer and ldm_reset_vbus(<wild>) panics the kernel (fatal trap in hpt_timeout/ldm_reset_vbus).
• Observed on the audit guest: no HighPoint PCI device exists (pciconf -l shows only i440FX/PIIX4/bochs-VGA/virtio), so the driver's hpt_probe() never attaches, hpt_final_init() prints "no controller detected", no /dev/hpt27xx node and no CAM sim are created, and the racing code paths are unreachable. See run.log.

Contents

• VERDICT.md — full narrative with path:line proof chain and the honest verification classification (not reproducible without the controller).
• race_proof.txt — annotated source walk of the race.
• verify_env.sh / run.sh — guest environment probe.
• run.log — actual probe output from the audit guest (2026-09-19).
• env.txt — guest uname, kernel, module state.
• fix.diff — git-apply-able fix (guarded reset under the vbus lock).
• manifest.json, verdict.json.

DF-4369 — VERDICT

Status: not_reproduced (hardware-gated — no RocketRAID 27xx controller on the audit guest). Static analysis: the race is real; confidence likely.

The bug

sys/dev/raid/hpt27xx/hpt27xx_osm_bsd.c arms a per-command timeout whenever a CAM read/write is queued:

• scatter/gather fast path: callout_reset(ccb->ccb_h.timeout_ch, HPT_OSM_TIMEOUT, hpt_timeout, pCmd) — hpt27xx_osm_bsd.c:730-731
• busdma path: same call from hpt_io_dmamap_callback — hpt27xx_osm_bsd.c:530-531

HPT_OSM_TIMEOUT is 20*hz (os_bsd.h:190).

The completion path os_cmddone() (hpt27xx_osm_bsd.c:421-466) runs from the interrupt / taskqueue context (always under the vbus lock, taken by hpt_pci_intr() at :836 or hpt_do_tasks() at :386):

static void os_cmddone(PCOMMAND pCmd)
{
    POS_CMDEXT ext = (POS_CMDEXT)pCmd->priv;      /* :423 */
    union ccb *ccb = ext->ccb;
    callout_stop(ccb->ccb_h.timeout_ch);          /* :428 — NOT synchronizing */
    ...
    cmdext_put(ext);                              /* :463 — ext back on free list */
    ldm_free_cmds(pCmd);                          /* :464 — pCmd back on LDM freelist */
    xpt_done(ccb);                                /* :465 */
}

The timeout handler runs in softclock context without any lock:

static void hpt_timeout(void *arg)                /* :411 */
{
    PCOMMAND pCmd = (PCOMMAND)arg;
    POS_CMDEXT ext = (POS_CMDEXT)pCmd->priv;      /* :414 — UAF read if freed */
    ldm_reset_vbus((PVBUS)ext->vbus_ext->vbus);   /* :418 — wild deref if recycled */
}

DragonFly's callout_stop() explicitly does not protect against this:

"Stops a callout if it is pending or queued, does not block. This function does not interlock against a callout that is in-progress." — sys/kern/kern_timeout.c:1087-1088 (contract in sys/sys/callout.h:131)

So the following interleaving is legal on an SMP box:

priv is a dedicated field of struct _COMMAND (him.h:417), not overlaid by freelist linkage, so after a plain free→idle it still points at the old (still mapped, contents-intact) OS_CMDEXT and the outcome is a benign spurious bus reset. The crash needs the freed PCOMMAND to be recycled before :414 runs:

• recycled as a flush command (hpt_flush_vdev, hpt27xx_osm_bsd.c:291-303): pCmd->priv = &done — a kernel stack address; ext->vbus_ext then reads stack garbage and ldm_reset_vbus() gets a wild pointer;
• recycled as an LDM-internal command (rebuild/verify, blob code): priv per the blob's internal convention (can be NULL → NULL-page deref).

Why it was not reproduced

The audit guest (QEMU/KVM, DragonFly 6.5-DEVELOPMENT X86_64_GENERIC) has the driver compiled in (sys/config/X86_64_GENERIC:117; kldstat -v shows 86 pci/hpt27xx) but no HighPoint controller: pciconf -l lists only i440FX/PIIX4/bochs-VGA/virtio devices, dmesg says hpt27xx: no controller detected. (hpt_final_init, hpt27xx_osm_bsd.c:1021), there is no /dev/hpt27xx and no CAM sim. The racing code paths (hpt_scsi_io → callout_reset → os_cmddone/hpt_timeout) are only reachable with a real RocketRAID 27xx doing I/O. See run.log.

No amount of guest-side setup can synthesize a PCI 0x1103 SAS controller, so this stays honestly not_reproduced (device absent), with the static proof above carrying the finding.

Field-trigger scenario (for the maintainer)

Any RocketRAID 27xx system under SMP with storage that completes a command in the same instant its 20-second deadline expires (failing/detaching disk, firmware stall recovering at ~20 s, heavy VM stall). Observed field symptom would be a Fatal double memory fault / panic in hpt_timeout on storage boxes, previously attributed to the controller.

Exploitability

Panic/DoS only: the corrupted dereference is a read; ldm_reset_vbus then chases a wild pointer. There is no attacker-controlled write primitive. Not a privilege-escalation path.

Fix

fix.diff — serialize hpt_timeout() with the completion path by taking the vbus lock (it is recursive: lockinit(..., LK_CANRECURSE), hpt27xx_osm_bsd.c:1040) and re-validating pCmd->priv before acting. If the command was recycled, priv no longer equals the captured ext and the reset is skipped; if it merely completed and sits idle on the freelist, the reset is equivalent to today's behavior but now race-free. callout_stop_sync() was deliberately NOT used: os_cmddone runs in interrupt context and hpt_timeout needs the same vbus lock, so a synchronizing stop would deadlock. Fix validation is not_testable on this guest (no hardware).

Verified-negative side work (same file, killed candidates)

See race_proof.txt appendix: the hpt_get_logical_devices count shuffle is clamped by the blob (disassembly: the lib's get-logical-devices returns min(total, maxcount)); the cmdext NULL-deref cannot happen (devq openings == cmdext pool size == os_max_queue_comm); the flush/ioctl sleep loops are lost-wakeup-safe because lksleep drops the lock atomically and completions run under the same lock.

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.