# DF-3895 — VERDICT

**Status: not_reproduced (hardware-gated) — defect certain from source.**
**Impact class (on real hardware): permanent adapter-wide I/O hang (DoS) +
high-priority command leak; CCBs never returned to CAM.**

## Proof chain

1. Early-exit-without-unwind sites:
   - `sys/dev/raid/mps/mps_sas.c:1303-1307` (`mpssas_send_reset`,
     `target->handle == 0` → `return -1`)
   - `sys/dev/raid/mps/mps_sas.c:1443-1447` (`mpssas_send_abort`,
     `targ->handle == 0` → `return -1`)
   In both, `tm` was already associated (`targ->tm == tm`, set by the
   caller at mps_sas.c:1531, or carried through escalation) and no
   `callout_reset` has been armed on this leg (those happen at
   mps_sas.c:1338/1466, after the handle check) — so nothing will ever
   complete or time this TM out.
2. All five call sites drop the return:
   mps_sas.c:1203, 1218 (`mpssas_logical_unit_reset_complete`),
   1418, 1428 (`mpssas_abort_complete`), 1536 (`mpssas_scsiio_timeout`).
3. Wedge mechanics: `targ->tm` is cleared only inside TM completion
   handlers (mps_sas.c:1165, 1206, 1251, 1278, 1384, 1409) — none of which
   will run; subsequent timeouts queue onto `targ->timedout_commands`
   forever (mps_sas.c:1522-1530); the victim CCBs never reach `xpt_done`;
   XPT_ABORT is faked-success (mps_sas.c:986-991) so nothing external can
   unwedge them; `tm_count` remains ≥1 (incremented in `mpssas_alloc_tm`,
   mps_sas.c:242) so `xpt_release_simq` never happens (mps_sas.c:262-265)
   — the SIM queue is frozen for the life of the adapter.
4. Provable trigger (twin of the mpr DF-3802 proof):
   `mpssas_remove_volume` zeroes `targ->handle` (mps_sas.c:387-397) **after
   issuing the TM but without draining `targ->commands`**, while
   `mpssas_remove_device` drains them ("Completing missed command",
   mps_sas.c:592-599). Outstanding volume I/O + a later timeout ⇒
   `mpssas_send_abort` sees handle==0 ⇒ -1 ⇒ wedge. Additionally,
   `mpssas_handle_reinit` zeroes *all* target handles (mps_sas.c:1113-1121)
   without purging `timedout_commands`, so a timeout processed in the
   rediscovery window wedges identically.

## Why not reproduced on this guest

No SAS2 HBA (env.txt, run.log); SIM never attaches; no mps command can time
out. On hardware the wedge is observable as: console spam from
`mpssas_send_abort`'s mps_printf, `camcontrol devlist` hangs on that bus,
all mps I/O blocked, `tm_count` stuck at 1 in MPS_TRACE logs.

## Exploitability

DoS. An unprivileged user with access to a volume/disk being deleted (or
any target during diag-reset rediscovery) whose I/O stalls can wedge the
entire adapter's I/O permanently. No memory-corruption primitive.

## Fix validation

Not testable on this guest. fix.diff ports the accepted DF-3802 fix
verbatim to mps (unwind on the -1 paths + drain in remove_volume).

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