# 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.