DF-3962 — hptiop mvfrey CCB-timeout callout runs iop_intr unlocked, racing the locked IRQ path (double SRB completion → UAF)

File: sys/dev/raid/hptiop/hptiop.c (pass 2; knowns DF-1311/1312/1313 excluded)

What

Every mvfrey SCSI command arms a 20 s per-CCB callout (callout_reset(ccb->ccb_h.timeout_ch, 20*hz, hptiop_reset_adapter, hba) hptiop.c:2647–2650). The handler hptiop_reset_adapter (2244–2250) calls hptiop_send_sync_msg (891–907) which polls hba->ops->iop_intr(hba) without hba->lock. The hard-IRQ path hptiop_pci_intr (2163–2169) runs the identical iop_intr with the lock. Two CPUs can therefore drain the mvfrey outlist concurrently through the non-atomic outlist_rptr loop (782–795): both process the same tag → hptiop_free_srb() twice (srb on the freelist twice → two CCBs share one srb) and xpt_done(ccb) twice (CAM UAF). Additionally: the timed-out CCB is never completed by its own timeout handler (callout arg is hba), and the reset path busy-waits up to 60 s (DELAY loop in softclock context).

Sibling HighPoint drivers lock in their timeout handlers (hptmv/entry.c:2626 lock_driver(); fResetVBus(), hpt27xx_osm_bsd.c:530) — hptiop is the outlier.

Build / Run (hardware recipe)

Needs an RR43xx/45xx (mvfrey family) present and a stalled command: kldload hptiop; saturate I/O; wedge/expel the device past 20 s while later completions still arrive; observe double-completion panic (xpt_done on a done ccb) or freelist aliasing corruption.

Expected

CAM assertion/panic xpt_done twice, or silent srb aliasing (two commands writing one request buffer) → memory corruption.

Honesty

Hardware-gated (no mvfrey HBA on guest). The race is certain from source: no lock, no atomics, shared cursors. The 60 s DELAY in a callout is independently a DoS.

DF-3962 verdict — certain source-level race, hardware-gated

Reproduced?

No: guest has no HighPoint/mvfrey device (env.txt). Source analysis is conclusive.

The race, path:line

1. hptiop.c:2647–2650 — per-CCB 20 s callout armed on every mvfrey SCSI post; arg is hba (not the ccb), so the timeout never completes its CCB.
2. hptiop.c:2244–2250 — hptiop_reset_adapter calls hptiop_send_sync_msg(hba, IOPMU_INBOUND_MSG0_RESET, 60000) with NO adapter lock. XPT_RESET_BUS calls it under the lock (2350–2353) — the lock is LK_CANRECURSE (1899) so fix.diff locking is safe for both paths.
3. hptiop.c:899–906 — hptiop_send_sync_msg polls hba->ops->iop_intr(hba) directly; for mvfrey that is hptiop_intr_mvfrey (760–802) which drains the outlist with the shared, non-atomic hba->u.mvfrey.outlist_rptr (782–795) and completes tags via hptiop_request_callback_mvfrey.
4. hptiop.c:2163–2169 — hptiop_pci_intr holds the lock around the same iop_intr; lock discipline is inconsistent between the two callers, so there is NO mutual exclusion between them.
5. Both CPUs can read the same outlist entry → same _tag completed twice → hptiop_free_srb twice (srb freelist aliasing: two future CCBs share one srb and its DMA request buffer) and xpt_done(ccb) twice (CAM UAF).
6. Bonus: 60000 ms of DELAY(1000) polling inside a callout (softclock context) starves the CPU; and reset wipes firmware queues while in-flight SRBs are never reaped (ccb leak / CAM wedge).

Sibling comparison: sys/dev/raid/hptmv/entry.c:2626-2633 and sys/dev/raid/hpt27xx/hpt27xx_osm_bsd.c:528-532 both take their driver lock inside the timeout handler before resetting.

Fix

fix.diff takes hptiop_lock_adapter around the reset in hptiop_reset_adapter (safe for the recursive XPT_RESET_BUS path). A fuller upstream fix should also abort/complete the timed-out CCB and avoid the 60 s busy-wait in callout context.

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.