DF-4591 / verdict.json
{ "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" } |