DF-4243 — send-failure path in dptexecuteccb leaves the timeout callout armed

dptexecuteccb arms the CCB timeout (callout_reset, dpt_scsi.c:778) before handing the command to the controller. If dpt_send_eata_command() then fails (HBA stays HA_ABUSY for ~1s: wedged/faulty controller), the error path at dpt_scsi.c:780-788 unloads the map, frees the dccb and xpt_done()s the ccb — but never callout_stop()s the armed timer (compare the normal completion path, which does: dpt_scsi.c:1572).

When the stale callout later fires, dpttimeout() runs on a freed/possibly recycled state: * dccb->ccb is stale → xpt_print_path(ccb->ccb_h.path) reads a possibly recycled CAM ccb (dpt_scsi.c:1683-1685); * if the dccb was already re-allocated to a new command, the DCCB_ACTIVE check passes and dpttimeout sends EATA_SPECIFIC_ABORT (dpt_scsi.c:1707) against the new, healthy command and stamps CAM_CMD_TIMEOUT on its ccb — premature abort of unrelated I/O.

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.