DF-4888 / verdict.json
{ "finding_id": "DF-4888", "status": "untested", "reproduced": 0, "impact": "Permanent BAR/rman resource leak on every failed attach; late attach failure (bus_setup_intr) leaks all DMA state and /dev/iirN and leaves XPT-registered CAM SIMs with no interrupt handler - CAM scan CCBs hang forever (iir_timeout empty), wedging the rescan thread; hardware-gated local DoS/resource exhaustion (CWE-404)", "confidence": "certain", "verdict": "Source-verified, hardware-gated: every iir_pci_attach error path leaks the BAR0 resource (release commented out at sys/dev/raid/iir/iir_pci.c:349-352, and the saved rid was clobbered to 0 at :195), and a bus_setup_intr failure after successful iir_init()/iir_attach() (:336-341) releases only the IRQ - no iir_free(), no XPT/sim/shutdown-handler teardown - leaving leaked pools plus live registered SIMs whose completions can never be delivered (CCBs hang; iir_timeout is empty per DF-4176). Not runnable on the audit guest: no Intel 0x8086:0x0600 / ICP controller exists in pciconf (env.txt); driver is compiled in (kldstat -v: 100 pci/iir) so the code path is live on any host with the card.", "exploit_chain": "", "evidence": "findings/poc/DF-4888/VERDICT.md (full path:line trace); findings/poc/DF-4888/fix.diff; guest hardware-absence proof in findings/poc/DF-4888/env.txt", "kernel_refs": [ "sys/dev/raid/iir/iir_pci.c:186", "sys/dev/raid/iir/iir_pci.c:195", "sys/dev/raid/iir/iir_pci.c:326", "sys/dev/raid/iir/iir_pci.c:333", "sys/dev/raid/iir/iir_pci.c:336", "sys/dev/raid/iir/iir_pci.c:346", "sys/dev/raid/iir/iir.c:199", "sys/dev/raid/iir/iir.c:272", "sys/dev/raid/iir/iir.c:494", "sys/dev/raid/iir/iir.c:514" ], "poc_changes": "no runnable PoC (hardware absent); evidence pack documents the trace and fix", "attempts": 0, "guest_uname": "DragonFly dfbsd 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": 0, "guest_dirty": 0, "build_cmd": "", "run_cmd": "", "code_hash": "", "notes": "Residual after fix.diff: iir_attach() itself leaves sims[i] dangling (non-NULL) when xpt_create_path() fails at bus i (iir.c:503-510); the fixs cleanup keys on paths[i] != NULL so it stays correct, but a follow-up should NULL sims[i] there. Severity Low consistent with sibling iir findings DF-4173/DF-4175/DF-4176.", "recommended_fix": "Save the memory rid and release io on every error path; on bus_setup_intr failure deregister XPT paths/SIMs, drop the shutdown handler and call iir_free() (see fix.diff)", "fix_status": "not_testable", "fix_baseline_reproduced": 0, "fix_patched_reproduced": 0, "fix_verdict": "fix.diff authored post-verification against the read-only sys/ tree; not build-validated (no controller hardware to attach the patched kernel to)", "fix_evidence": "findings/poc/DF-4888/fix.diff" } |