DF-4400 — tws_intr_resp invokes req->cb with no state validation (double completion / NULL cb)

What

sys/dev/raid/tws/tws_cam.c:1156-1173:

while ( tws_get_response(sc, &req_id, &mfa) ) {
    ...
    if ( req_id == TWS_INVALID_REQID ) { ... tws_err_complete(sc, mfa); continue; }
    sc->reqs[req_id].cb(&sc->reqs[req_id]);   /* <-- no bounds, no state check */
}

Two distinct defects beyond DF-1590 (which covers the out-of-bounds index):

1. No busy-state validation. req->cb is only initialized when a request is allocated (tws_get_request, tws.c:803-814, which also sets cb = NULL) or explicitly by the submitter; it is never cleared on release. A firmware-fed in-range req_id that is stale (duplicate response for an already-completed request, or a response for a FREE slot) invokes the old callback: - stale tws_scsi_complete (tws_cam.c:738) on a completed request → xpt_done(ccb) a second time on a ccb CAM may already have recycled, and callout_stop(req->ccb_ptr->ccb_h.timeout_ch) on dead ccb memory; - if the slot was reallocated, req->ccb_ptr is the new, in-flight ccb → the new transaction is completed early while the firmware still owns it (biodone of an in-flight bio — the tws/twa sibling bug DF-4178's signature).
2. NULL callback call. tws_get_param() deliberately submits with req->cb = NULL (tws_cam.c:924) because it polls for the response (:941-942). If an interrupt ever delivers that response first, sc->reqs[3].cb(...) is a NULL function-pointer call → panic. (Today this is latent: tws_get_param runs only at attach with interrupts masked, tws.c:547 / tws_hdm.c:112-114 — but nothing enforces it.)

Impact

Device-fed trigger (misbehaving/duplicating firmware — same threat model as DF-1590): kernel NULL-call panic or CAM use-after-free / double-done list corruption. The response loop also terminates only when the firmware stops producing responses (tws_get_response false), so a hostile controller can keep the interrupt handler spinning through arbitrary stale callbacks.

Trigger

No local trigger — requires the controller to emit a duplicate/stale response. Documented in VERDICT.md; trigger.c is a compile-only stub that documents the expected response word (16-bit request_id bitfield, tws_hdm.h:348-353).

Status

QEMU guest has no 3ware HBA → inconclusive; logic proven from source.

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.