DF-3921 — hptmv registers panic("Here") as its AC_LOST_DEVICE async callback

What

sys/dev/raid/hptmv/entry.c:2070-2075 (hpt_attach):

xpt_setup_ccb(&ccb->ccb_h, pAdapter->path, 5);
ccb->ccb_h.func_code = XPT_SASYNC_CB;
ccb->csa.event_enable = AC_LOST_DEVICE;
ccb->csa.callback = hpt_async;

and the callback itself (entry.c:2142-2153) is a stub left from debugging:

static void hpt_async(void *callback_arg, u_int32_t code, struct cam_path *path, void *arg)
{
    /* debug XXXX */
    panic("Here");

Impact

Any xpt_async(AC_LOST_DEVICE, ...) broadcast on the hptmv bus panics the kernel. CAM emits AC_LOST_DEVICE when a previously-probed target disappears at rescan (sys/bus/cam/cam_xpt.c:6221-6223 probe-inquiry failure; :6382-6384 device changed; sys/bus/cam/cam_periph.c:1764 periph invalidation). On a RAID controller, losing a member disk is the normal failure mode: the next boot rescan / camcontrol rescan / CAM error-recovery scan panics the box instead of degrading the array. Reliable local DoS triggered by a hardware event (or by root via camcontrol). Severity Medium, confidence certain.

Reproduce (needs RR1820 hardware)

1. Attach hptmv controller with >= 1 disk; let CAM probe it.
2. Remove / power off the disk (or camcontrol rescan after failure).
3. Rescan the bus → probe fails inquiry → AC_LOST_DEVICE → panic("Here").

Fix

--- a/sys/dev/raid/hptmv/entry.c
+++ b/sys/dev/raid/hptmv/entry.c
@@ -2145,11 +2145,8 @@ hpt_async(void * callback_arg, u_int32_t code, struct cam_path * path,
     void * arg)
 {
-   /* debug XXXX */
-   panic("Here");
    UNREFERENCED_PARAMETER(callback_arg);
    UNREFERENCED_PARAMETER(code);
    UNREFERENCED_PARAMETER(path);
    UNREFERENCED_PARAMETER(arg);
 }

(i.e. turn it into the intended no-op; the driver already handles device loss via its own sata-event path, entry.c:850-901.)

DF-3921 VERDICT

status: not_reproduced (hardware-gated) | impact observed: none (potential: dos/panic) | source certainty: certain

Reproduced?

No. Requires an hptmv (11ab:5081) controller; the audit guest has none (env.txt). The panic is nonetheless unconditional at source level: the registered callback body is panic("Here") with no condition (entry.c:2147), and the event that invokes it (AC_LOST_DEVICE) is a standard CAM broadcast whenever a probed target vanishes at rescan (cam_xpt.c:6223/6384, cam_periph.c:1764). There is no code path in which hpt_async runs and does anything other than panic.

Trace

• entry.c:2071-2074 — XPT_SASYNC_CB registration for AC_LOST_DEVICE with callback hpt_async on the adapter path (CAM_TARGET/LUN wildcard).
• cam_xpt.c:6221-6223 — probe finds device gone → xpt_async(AC_LOST_DEVICE, path, NULL).
• xpt_async walks registered async clients and calls hpt_async → entry.c:2147 panic("Here").

Realistic trigger on real hardware

RR1820 member disk dies or is hot-removed (expected RAID event) → next bus scan (boot, camcontrol rescan, CAM error recovery) → kernel panic. Also directly triggerable by root: camcontrol rescan <bus> after pulling a disk.

Fix validation

Not possible without the controller. fix.diff replaces the panic with the intended no-op.

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.