# DF-4509 — twa(4) `tw_cli_drain_aen_queue()` FREE_Q double-insert on ETIMEDOUT (request left dual-linked in BUSY_Q/PENDING_Q + FREE_Q)

* **File:** `sys/dev/raid/twa/tw_cl_misc.c:309-386` (out: label `:379-384`, ETIMEDOUT break `:353-356`)
* **Class:** queue-discipline / latent use-after-free (memcorrupt bucket)
* **Siblings:** DF-4335 (get/set_param requeue), DF-4274 (OSL passthru), DF-1814 (init_connection)

## What it is

When the 3ware firmware stops completing commands, the controller-reset path
calls `tw_cli_drain_aen_queue()`, which submits a REQUEST_SENSE by internal
request and polls for `TW_CLI_REQUEST_TIMEOUT_PERIOD`.  The request is at that
moment linked into `TW_CLI_BUSY_Q` (`tw_cl_io.c:219`) or
`TW_CLI_PENDING_Q` (`tw_cl_io.c:204`).  If the poll times out, the function
breaks to its `out:` label and unconditionally inserts the same request into
`TW_CLI_FREE_Q` — without unlinking it from the queue it still occupies.  The
list macros (`TW_CL_Q_INSERT_TAIL`, `tw_cl_share.h:284-289`) overwrite the
item's next/prev, cross-linking the two rings: the request can subsequently be
handed out by `tw_cli_get_request()` while the firmware still owns it, its
`internal_req_data` DMA buffer is re-assigned to a second command, and the
later firmware completion / reset drain completes the reused request into the
wrong owner's callback.  Same corruption class as DF-4335/DF-4274, third
distinct site.

## Reproduce (on twa-equipped hardware)

1. `./build.sh && ./run.sh` — run.sh is a presence prober; it lists `/dev/twa*`.
2. Real trigger: hang the controller firmware (fatal drive-slot fault, or
   `devctl`-detach the device MMIO region while I/O is in flight) so the
   watchdog/passthru-timeout reset path fires; the reset's post-reset AEN drain
   then hits the 60s REQUEST_SENSE timeout and the request is double-queued.
   Expected observation: subsequent `kldunload`/reset hangs, duplicated
   completions in the trace buffer, or a panic in the request queue walk.

## On the audit guest

`twa_probe` reports `no /dev/twa* nodes ... controller ABSENT`.  The QEMU
guest has no 3ware 9000-series PCI device; the driver never attaches.  The
defect is proven by code inspection in `VERDICT.md` (deterministic queue-state
analysis); verdict: **inconclusive** (hardware absent), not a false positive.

## Fix

`fix.diff` — unlink the request from BUSY_Q/PENDING_Q at the `out:` label
before inserting it into FREE_Q.