# DF-4243 verdict — UNTESTED (hardware-gated); callout leak certain from source

## Reproduced?
No — triggering requires a DPT controller wedged in HA_ABUSY long enough to
fail dpt_send_eata_command (dpt_scsi.c:1111-1119), then the (tens of
seconds) SCSI timeout to fire on the stale callout. No hardware in guest.

## Certainty
The asymmetry is provable: callout_reset at dpt_scsi.c:778 vs no
callout_stop in the 780-788 failure path, while the completion path stops
it at 1572. After xpt_done() the CAM ccb (and its embedded timeout_ch) is
owned by the periph again — a later dpttimeout() on it is a
use-after-free read (xpt_print_path) at minimum, and a premature abort of
whatever the recycled dccb is now doing at worst. Severity Low: requires a
wedged HBA to arm, and the damage is mostly availability.

## Fix validation
Not possible without hardware; fix.diff adds the one-line callout_stop.

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