# DF-4274 — twa(4) deferred-busdma error path returns a passthrough request to the free queue twice

File: `sys/dev/raid/twa/tw_osl_freebsd.c` (pass 2)

## What this pack contains

- `VERDICT.md` — full code-path proof of the double free-queue insertion and
  the platform-reachability analysis (latent on current x86-64 defaults).
- `fix.diff` — minimal conditional fix.
- `manifest.json`, `verdict.json`.
- No runnable PoC exists: triggering requires a 3ware 9000 HBA (absent from
  the audit guest — see `../DF-4273/env.txt`) **and** a `bus_dmamap_load()`
  deferral (`EINPROGRESS`), which the driver's DMA tags cannot produce on
  default-configured x86-64 (analysis in `VERDICT.md`).

## The defect (code-only proof)

`tw_osli_map_request()` (`tw_osl_freebsd.c:1390-1401`) handles
`bus_dmamap_load() == EINPROGRESS` by marking the request
`TW_OSLI_REQ_FLAGS_IN_PROGRESS` and letting the originator sleep.  When the
deferred load later completes and CL submission fails,
`twa_map_load_data_callback()` (`:1273-1284`) calls the completion callback
(`tw_osl_complete_passthru`, which wakes the sleeping ioctl thread — the
originator always unwinds through `fw_passthru_err` at `:1040-1049` and
inserts the request into `TW_OSLI_FREE_Q` itself) **and then also inserts the
same request into `TW_OSLI_FREE_Q` again** (`:1282-1283`).  Two unconditional
insertions of one `tw_cl_link` corrupt the free queue (self-referential ring)
and hand the same request context to two threads; the second owner's
`req->data` can be freed by the first owner's error path — double-free/UAF
class.