# DF-4591 VERDICT — not_reproduced (hardware-gated), defect certain from source

## Finding

The attach-failure unwinds of `tws_attach()` (sys/dev/raid/tws/tws.c:309-341)
release only the char device (315-316), the IRQ resource (318-322) and the
memory BARs (326-335).  They leak:

1. **MSI vectors** — allocated by `pci_alloc_1intr()` inside
   `tws_setup_irq()` (tws.c:426) before any attach_fail_4/3 exit;
   `pci_release_msi()` exists **only** in tws_detach (tws.c:381-382),
   proving the authors knew the release was required and omitted it on
   the error path.  Exits affected: `bus_setup_intr` failure (432-436),
   `tws_init` FAILURE incl. `tws_ctlr_reset` failure (289-292, 541-543),
   `tws_init_ctlr` FAILURE (293-296), `tws_cam_attach` error (297-300).
2. **Kernel heap** — `sc->reqs` (kmalloc at :535), `sc->sense_bufs`
   (:537), `sc->scan_ccb` (:539), `sc->aen_q.q` (:580), and
   `sc->trace_q.q` — the trace queue is allocated at tws_attach:202,
   before the earliest failure label, so **every** failed attach leaks it.
3. **DMA resources** — per-request maps from `bus_dmamap_create`
   (tws_init_reqs :610), the command DMA map + memory (:499-509), and the
   parent/cmd/data bus_dma tags (:465-530).  (tws_detach likewise never
   frees the maps/tags/dma_mem — same gap, fixed together.)

Aggregate ≈200 KB M_TWS heap + DMA resources + 1 MSI vector per failed
attach.  The failure is most reachable exactly when hardware is flaky
(`tws_init` returns FAILURE at :541-543 when `tws_ctlr_ready()` fails and
`tws_ctlr_reset()` fails — the DF-1924/DF-1925 wedged-controller state),
i.e. during operator load/unload retry loops → unbounded repeatable leak.

## Reproduction attempt on the audit guest

* Guest: DragonFly 6.5-DEVELOPMENT X86_64_GENERIC (env.txt).
* run.sh / run.log / guest_probe.log: no LSI 3ware (0x13C1) PCI device;
  tws compiled into the kernel, `dev.tws` absent, no /dev/tws* — the
  attach path never runs, so the leak cannot manifest:
  **status not_reproduced, reproduced=0, impact none (not manifested
  here)**.  Realistic impact ceiling on real hardware: permanent kernel
  memory / MSI-vector exhaustion via repeated failed loads (privileged,
  root trigger; Low severity).

Confidence: certain — the asymmetry with tws_detach:381-382/398-402 is
mechanical; every leaked allocation is cited to its exact line.

## Fix validation

fix.diff: attach_fail_4 gains callout cancellation + `pci_release_msi`;
attach_fail_1 frees every guarded allocation in reverse order (maps →
reqs → sense_bufs → scan_ccb → aen_q → trace_q → cmd dma map/mem →
data/cmd/parent tags); tws_detach gains the missing map/tag/dma_mem
cleanup.  `git apply --check` passes.  Baseline vs patched cannot be
exercised on this guest (no 3ware HW) → fix_status: not_testable;
validated by inspection.

## Artifacts

* trigger.sh — failed-attach load-cycle recipe + leak observation points
* run.sh, run.log, guest_probe.log, env.txt — guest hardware-absence proof
* fix.diff — error-unwind cleanup (git-apply clean, self-contained)
* manifest.json / verdict.json

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