# DF-4841 — VERDICT

**Finding:** post-reset OBFL refill no-op — `sc->sense_bufs[i].posted`
survives the controller soft reset, so `tws_init_obfl_q()` re-run by the
recovery path posts nothing and the firmware is left with zero response
frames → permanent I/O hang after any reset recovery.

## Reproduced? NO — hardware-gated on this guest (defect certain from source)

`guest_probe.log`: no 3ware (13c1) PCI device on the guest, `dev.tws`
absent, tws not a loadable module here (compiled into X86_64_GENERIC).
QEMU cannot emulate a 9750 controller. Same verification posture as the
other tws hardware findings (DF-1924/1925/1926/4590/4591).

## Why the defect is certain from the driver's own code

1. The reset path re-runs the refill *intending to re-post*:
   `tws_reinit()` resets `sc->obfl_q_overrun = false` and calls
   `tws_init_obfl_q(sc)` (tws_cam.c:1262-1266) — a function whose only
   job is putting frames into the firmware's outbound free list.
2. The refill posts only frames with `!posted` (tws_hdm.c:128).
3. `posted` is set true for all 256 frames during normal operation
   (tws_hdm.c:141) and is cleared at exactly two sites: attach
   (`tws_init_reqs`, tws.c:620) and a failed repost on OBFL overrun
   (tws_cam.c:543). Neither runs on the reset path
   (tws_reset → tws_reset_cb → tws_reinit, tws_cam.c:1198-1266).
4. Therefore, after a soft reset wipes the firmware's queue state,
   `tws_init_obfl_q()` posts nothing. Invariants (2)+(3) and the intent
   (1) are mutually exclusive — the recovery path is self-defeating:
   `tws_init_connect()` polls 60 s (TWS_POLL_TIMEOUT, tws.h:74) for a
   response through the very queue it failed to refill, then every
   subsequent command times out forever. (If one instead assumed the
   queue SURVIVES the reset, the `obfl_q_overrun=false` + refill call
   in `tws_reinit` would be dead code.)

Impact ceiling: local DoS of the storage adapter and all I/O bound to
it (system-wide stall for root/boot disks on it), reachable from any
controller error that enters `tws_reset()` — including DF-4401's
unguarded re-entry and DF-4590's stale-callot storms. Root/privileged
or hardware-fault trigger; Low severity per the audit rubric
(aligned with DF-1924/1925/1926).

Distinct from known findings: DF-1924/1925 (unbounded spins — hang
*inside* the spin loops), DF-1926 (request-slot leak on init_connect
failure). This finding is the *successful*-reset case: reset completes,
recovery runs to completion, and the adapter is still dead because the
refill was a no-op.

## Fix

`fix.diff`: `tws_reset_obfl_q()` (tws_hdm.c) clears all `posted` flags;
`tws_reinit()` (tws_cam.c) calls it before `tws_init_obfl_q()`.
Not inside `tws_init_obfl_q()` itself — the OBFL-overrun caller
(tws_hdm.c:282-284) must not double-post frames still queued.
git-apply clean against the tree (dry-run verified). Not runtime
validated: no controller on the audit guest.

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