# VERDICT — DF-4400

**Status: inconclusive (hardware-gated).** The defect is certain from source;
triggering requires the 3ware controller to emit a duplicate or stale response
(same device-fed trust that DF-1590 documents for the OOB-index aspect).

## Proof chain

1. `tws_get_response()` (`tws_hdm.c:354-381`) extracts `request_id` from a
   16-bit firmware bitfield (`struct tws_outbound_response`,
   `tws_hdm.h:348-353`).
2. `tws_intr_resp()` (`tws_cam.c:1161-1171`) treats every non-`TWS_INVALID_REQID`
   value as an in-flight request and calls `sc->reqs[req_id].cb(...)` — no
   bounds check (that is DF-1590) **and no check that the request is BUSY /
   has a completer**.
3. Request lifecycle (`tws.c:744-828`): `cb` is assigned per submission
   (`tws_cam.c:738, 829, 875`; `tws_user.c:124`) and reset to NULL only on the
   *next* allocation (`tws.c:812`); release paths (`tws_q_insert_tail` to
   FREE_Q at `tws_scsi_complete`, `tws_cam.c:374-376`) never clear it, and
   reserved slots 0-3 are gated by `state` alone (never queued).
4. Consequence for a stale/duplicate in-range id:
   - completed slot: `tws_scsi_complete` runs again → `tws_q_remove_request`
     harmlessly returns NULL (`tws_services.c:314-362`) but
     `callout_stop(req->ccb_ptr->ccb_h.timeout_ch)` (`tws_cam.c:365`) touches a
     ccb already surrendered via `xpt_done` (`:371`), and `xpt_done` runs a
     second time (`:371`) → CAM done-queue double-insert / UAF (ccb recycled by
     periph between the two completions).
   - reallocated slot: early `xpt_done` of the new, firmware-owned ccb →
     biodone of an in-flight bio (identical class to twe DF-4178).
5. NULL-cb instance: `tws_get_param` submits `reqs[3]` with `cb = NULL`
   (`tws_cam.c:924`, submit at `:941`) and polls (`:942`); any interrupt that
   delivers that response first (`tws_intr_resp`) calls NULL → panic.
   Currently masked because `tws_get_param` runs only during attach
   (`tws_hdm.c:218-225` → `tws_init_ctlr:112`) with interrupts off
   (`tws.c:547`, turned on only at `tws_hdm.c:114`).

## Impact ceiling
Panic (NULL cb, double-done) or CAM-layer memory corruption from
device-controlled completion replay. Not locally triggerable by an unprivileged
user; requires errant/hostile firmware — rated Medium to stay consistent with
DF-1590 (same trust boundary, comparable primitive).

## Fix
Validate the request before invoking the callback (and, belt-and-braces, the
bounds — see fix.diff, which also closes DF-1590's window at this call site).

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