{
  "finding_id": "DF-2305",
  "status": "reproduced",
  "reproduced": 1,
  "impact": "leak",
  "confidence": "certain",
  "verdict": "Forced-failure interposition of bus_dma_tag_create exactly at its fwohci_pci.c:300 call inside the REAL fwohci_pci_attach (verbatim TU rig) returned ENOMEM at fwohci_pci.c:320-324 with NO cleanup: rig resource accounting captured MEM 1 alloc / 0 releases, IRQ 1/0, setup_intr 1 / teardown 0, live_handlers=1 (BAR + IRQ leaked, fwohci_intr still registered), console showed the stock Could-not-allocate-DMA-tag kprintf followed by no release activity. A clean re-attach was then refused by the rman BAR-conflict model (Could not map memory, ENXIO) and the failed re-attach overwrote sc->bsr with NULL, orphaning the BAR permanently. The sibling error path (irq alloc failure at :280) run through the same rig was balanced (MEM 1/1) because it calls fwohci_pci_detach; a rig-only forced detach of the leaked state released exactly what the stock path left behind. Additional finding during verification: after the failed attach, device_doattach calls device_set_driver(dev, NULL) which kfrees the softc (subr_bus.c:2121) while the handler stays registered, so on real shared-IRQ hardware the leaked handler dispatches into freed memory. Reachability is hardware-gated (needs an OHCI-1394 card) plus a genuine bus_dma_tag_create ENOMEM (alloc_bounce_pages path on >4GB hosts under memory pressure; the tag kmalloc is M_INTWAIT), so rare in practice but deterministic once it fires. Low severity confirmed; fixed by hunk 2 of fix.diff (adds the missing detach), A/B validated: balanced accounting and re-attach unblocked on the fixed kernel.",
  "exploit_chain": "",
  "evidence": "run.log: test A deltas (MEM 1/0 IRQ 1/0 setup 1 teardown 0 live_handlers=1, rc=12), test C forced-detach releases all, test D sibling balanced MEM 1/1, test B re-attach conflict rc=6. dmesg.txt: stock console lines (Could not allocate DMA tag - error 12 with no cleanup following; Could not allocate irq then MEM released on the sibling path; Could not map memory on the conflict path). run_fixed.log: fixed kernel balanced (1/1, 1/1, teardown 1, live 0) and re-attach unblocked (zero conflicts).",
  "kernel_refs": [
    "sys/bus/firewire/fwohci_pci.c:320-324",
    "sys/bus/firewire/fwohci_pci.c:278-284",
    "sys/bus/firewire/fwohci_pci.c:287-298",
    "sys/bus/firewire/fwohci_pci.c:267-272",
    "sys/platform/pc64/x86_64/busdma_machdep.c:820-860",
    "sys/kern/subr_bus.c:2121"
  ],
  "poc_changes": "Built on the new fwpci_harness.c rig (shared with DF-2304): counter-based fail-exactly-at-Nth interposition of bus_dma_tag_create; accounting built into the fabricated pci bus methods; rman-style BAR-conflict model to demonstrate permanence; rig softc preserves leaked resource pointers across runs so a forced detach can prove what the missing cleanup would release.",
  "attempts": 2,
  "guest_uname": "DragonFly dfbsd 6.5-DEVELOPMENT DragonFly 6.5-DEVELOPMENT #2: Sun Oct 18 14:03:54 UTC 2026 root@dfbsd:/usr/obj/usr/src/sys/FWO x86_64",
  "runtime_sec": 600,
  "guest_dirty": 1,
  "build_cmd": "sh /root/fwo/fwpci_prep.sh && sh /root/fwo/build_kernel.sh (nativekernel KERNCONF=FWO) ; cc -O -Wall -o fwpcictl fwpcictl.c",
  "run_cmd": "sh /root/fwo/run.sh  (fwpcictl attach dmatagfail / forcedetach / attach irqfail / attach, as root)",
  "code_hash": "fe15a597dd10cab0a921f14900768d16933a756bac1fad238730ce4d93396ac5",
  "notes": "Guest has no OHCI hardware; PCI externalities are fabricated kobj machinery while the audited attach/detach code runs byte-identical. The failed re-attach orphaning sc->bsr (assignment at fwohci_pci.c:267) makes the leak unrecoverable even manually after a second attempt.",
  "recommended_fix": "Call fwohci_pci_detach(self) before the ENOMEM return at fwohci_pci.c:323, mirroring the sibling error paths at :282/:296/:330."
}