# VERDICT -- DF-2031 (Low)

**Verdict:** REPRODUCED (source-only)

**Impact:** resource leak (BAR/DMA-tag/MSI) on failed attach; HW-gated (needs mfi(4)), source-confirmed

**Confidence:** likely

## Mechanism (source-traced)

mfi_pci_attach (mfi_pci.c:288-292): if bus_alloc_resource_any(SYS_RES_IRQ) returns NULL, the code executes 'device_printf; return(EINVAL);' at mfi_pci.c:290-291, bypassing the out: cleanup label at :295 that invokes mfi_free()/mfi_pci_free(). This orphans the already-allocated PCI memory BAR (:260), parent DMA tag (:271-279), and committed MSI vector. The sibling DMA-tag failure path at :280-281 correctly does 'goto out'.

## Why not runtime-reproduced

The guest (DragonFlyBSD 6.5-DEVELOPMENT #0 master DEV, KVM) has NO matching
hardware: pciconf shows no mfi/tws/iir RAID controller and no amdgpu/DRM GPU;
the driver therefore cannot attach and the vulnerable path is not runtime-
triggerable here. The defect was **confirmed at the source level** by tracing
the cited `path:line` against `sys/`, and the proposed fix was applied and the
affected module (`mfi`) built clean with `-Werror` (see fix_build.log).

## Fix

mfi_pci.c:290-291: change 'return(EINVAL)' to 'error = EINVAL; goto out' so the already-allocated BAR/DMA-tag/MSI resources are released through the out: label.

The standalone, git-apply-able diff is `fix.diff`.