{
  "finding_id": "DF-4591",
  "status": "not_reproduced",
  "reproduced": 0,
  "impact": "none",
  "confidence": "certain",
  "verdict": "The attach-failure unwinds of tws_attach() (tws.c:309-341) release only the cdev, IRQ resource and BARs. They (1) never call pci_release_msi() for the MSI allocation made in tws_setup_irq() (tws.c:426) even though tws_detach() does exactly that at tws.c:381-382 - direct evidence the release was known-required and omitted on the error path; and (2) free none of sc->reqs (535), sc->sense_bufs (537), sc->scan_ccb (539), sc->aen_q.q (580), sc->trace_q.q (allocated at tws_attach:202, leaked even by the earliest attach_fail_1 exit), the per-request bus_dmamap_create maps (610), the command DMA map/memory (499-509) or the three bus_dma tags (465-530). Every failed attach leaks ~200 KB of M_TWS kernel heap + DMA resources + one MSI vector, and failure is most reachable exactly with flaky hardware (tws_init FAILURE at 541-543 when the controller fails tws_ctlr_ready/tws_ctlr_reset - the DF-1924/1925 wedged-controller state) where operators retry load/unload cycles. tws_detach() also never frees the maps/tags/dma_mem (same cleanup gap, included in fix.diff). Not reproduced on the audit guest: no 3ware 13C1:1010 device exists (run.log/env.txt/guest_probe.log; vmstat -m shows no twsbuf; dev.tws absent), and QEMU cannot emulate the controller. Defect certain from source by the detach/error-path asymmetry.",
  "exploit_chain": "",
  "evidence": "VERDICT.md (allocation-vs-unwind line map with the detach:381-382/398-402 symmetry proof); trigger.sh (failed-attach load-cycle recipe + vmstat observation points); run.log/env.txt/guest_probe.log (no 3ware HW on guest); fix.diff (guarded cleanup of maps/reqs/sense/scan_ccb/aen_q/trace_q/dma map+mem/3 tags in attach_fail_1 + pci_release_msi in attach_fail_4 + detach-side map/tag cleanup; git-apply clean)",
  "kernel_refs": [
    "sys/dev/raid/tws/tws.c:202",
    "sys/dev/raid/tws/tws.c:309",
    "sys/dev/raid/tws/tws.c:317",
    "sys/dev/raid/tws/tws.c:336",
    "sys/dev/raid/tws/tws.c:381",
    "sys/dev/raid/tws/tws.c:426",
    "sys/dev/raid/tws/tws.c:499",
    "sys/dev/raid/tws/tws.c:535",
    "sys/dev/raid/tws/tws.c:610"
  ],
  "poc_changes": "No seed pack existed; trigger authored as documented failed-attach recipe plus guest hardware-absence probe.",
  "attempts": 1,
  "guest_uname": "DragonFly dfbsd 6.5-DEVELOPMENT DragonFly 6.5-DEVELOPMENT #0: Thu Jul  2 06:02:54 UTC 2026 root@dfbsd:/usr/obj/usr/src/sys/X86_64_GENERIC x86_64",
  "runtime_sec": 12,
  "guest_dirty": 0,
  "build_cmd": "n/a (hardware-gated; no guest-compilable trigger)",
  "run_cmd": "./run.sh",
  "code_hash": "44474ce01574f0d5616e96dd0ec7624a7e8c88d2fbde6086df70579fc6d6ddfc",
  "notes": "Hardware-gated (3ware 13C1:1010 required; guest has none). Ceiling: unbounded repeatable kernel-memory + MSI-vector exhaustion via failed-attach load cycles; root-privileged trigger (Low severity). Distinct from DF-1731 (NULL-deref window, not a leak) and from twa sibling DF-4273 (unvalidated passthru length).",
  "recommended_fix": "Release the MSI allocation in the attach-failure unwinds and free every guarded allocation (maps, reqs, sense_bufs, scan_ccb, aen_q, trace_q, cmd DMA map/mem, bus_dma tags) - see fix.diff.",
  "fix_status": "not_testable",
  "fix_baseline_reproduced": 0,
  "fix_patched_reproduced": 0,
  "fix_verdict": "Fix not validated on guest: baseline cannot run (no 3ware controller). fix.diff is git-apply clean and mirrors the cleanup tws_detach already performs for the same resources; validated by inspection.",
  "fix_evidence": "findings/poc/DF-4591/fix.diff"
}