DF-5154 — dpt_pci_attach() leaks parent_dmat on the dpt_init() failure path (dpt_free() never destroys the glue's DMA tag)

File: sys/dev/raid/dpt/dpt_pci.c:134-156 Class: resource leak on error path (CWE-401) Severity: Info (one-shot, hardware-gated, boot/kldload-time only) Distinct from DF-2151 (known, not re-reported): DF-2151 is the wrong-rid bus_release_resource; this is the DMA-tag lifecycle gap. Also distinct from DF-5153 (the bus_setup_intr-failure unwind): that path additionally leaks parent_dmat too, but this finding is the one that fires even on the earlier, otherwise-correct dpt_init failure path where dpt_free is called.

The bug

The PCI glue creates the parent DMA tag (dpt_pci.c:134-143):

    if (bus_dma_tag_create(/*parent*/NULL, ..., &dpt->parent_dmat) != 0) {
        dpt_free(dpt);
        error = ENXIO;
        goto bad;
    }
    ...
    if (dpt_init(dpt) != 0) {          /* dpt_pci.c:151 */
        dpt_free(dpt);             /* <-- frees children only */
        error = ENXIO;
        crit_exit();
        goto bad;
    }

dpt_free (dpt_scsi.c:1172-1204) unwinds exactly the objects dpt_init created, stepping init_level 5→0: dccb_dmamap unload/free/destroy, dccb_dmat, buffer_dmat, the sg-map list and sg_dmat. It never touches parent_dmat — the tag the glue created before dpt_init ran. rg parent_dmat sys/dev/raid/dpt/ shows the full picture: created once (dpt_pci.c:143), consumed as the parent of the three child tags (dpt_scsi.c:1235/1356/1370), destroyed nowhere. On the dpt_init failure path the tag (and its reference on the bus DMA machinery) leaks permanently. The success path never destroys it either — but there the driver intentionally keeps it for the device lifetime (there is no detach method at all), so only the error path is a defect.

Impact

Bounded: one bus_dma_tag_t + policy copy leaked per failed attach of a DPT 0x1044:0xa400 controller. Requires the real HBA present and dpt_init failing (board config handshake failure, DMA tag creation failure inside dpt_init, CCB allocation failure). No unprivileged trigger; no memory-safety consequence; correctness/hygiene only. Filed as hardening completeness so the family's teardown story is whole (mlx/ips/ida/amr/mfi siblings each got their unwind findings this pass).

Fix

fix.diff: destroy parent_dmat after dpt_free(dpt) on the dpt_init-failure path (child tags are destroyed by dpt_free, so the parent destroy afterwards is legal). DF-5153's fix performs the same destroy on the later bus_setup_intr-failure path.

DF-5154 VERDICT — parent_dmat leak on dpt_init failure

Status: untested (hardware-gated — no DPT controller on the audit guest, pciconf -l shows no 0x1044 device; see env.txt). Impact: none demonstrable on the guest — the defect itself is line-proven (confidence: certain), the impact is a bounded boot-time resource leak on real hardware only. Fix: authored (fix.diff, applies clean via git apply --check); fix validation not_testable (baseline cannot be reproduced without the HBA).

1. Root cause (line-certain)

• sys/dev/raid/dpt/dpt_pci.c:134-143 — glue creates dpt->parent_dmat (parent NULL, i.e. rooted at the bus's own tag).
• sys/dev/raid/dpt/dpt_pci.c:151-156 — on dpt_init failure the glue calls dpt_free(dpt) and returns; parent_dmat is never destroyed.
• sys/dev/raid/dpt/dpt_scsi.c:1172-1204 — dpt_free teardown ladder (init_level 5→0) destroys dccb_dmamap/dccb_dmat/buffer_dmat/ sg-maps/sg_dmat — all objects dpt_init created. parent_dmat was created by the glue before dpt_init, and dpt_free is common code shared with no other glue in this tree (dpt_pci.c is the only caller of dpt_alloc/dpt_free in sys/dev/raid/dpt/), so the omission is simply a split-responsibility bug: nobody owns the destroy.
• Exhaustive reference check: rg -n parent_dmat sys/dev/raid/dpt/ → creation (dpt_pci.c:143), three child-tag uses (dpt_scsi.c:1235, :1356, :1370), softc declaration (dpt.h:986). No bus_dma_tag_destroy of it anywhere.

2. Reachability / threat model

Requires a DPT SmartRAID PCI HBA (probe match at dpt_pci.c:61-66) and a dpt_init failure (config handshake via dpt_get_conf, DMA tag/CCB/sg-map allocation failures — several are device-fed, cf. DF-4245). Both conditions are boot/kldload-time; no unprivileged trigger, no user-controllable input, no kernel-memory consequence — the leak is a bus_dma_tag_t plus policy state per failed attach. Severity Info; would be Low only if a repeat-attach loop were possible (newbus does not retry failed attaches).

3. Why untested

Same hardware gating as DF-5153: the guest has no DPT device, so the path cannot be entered even by a KLD harness without fabricating the entire HBA config handshake (which would demonstrate nothing beyond the code text — the leak is directly readable from the source: create-without-destroy). Family precedent: DF-5115 (untested, analysis-verified).

4. Fix

fix.diff — bus_dma_tag_destroy(dpt->parent_dmat) after dpt_free(dpt) on the dpt_init-failure path; ordering is legal because dpt_free has already destroyed the three child tags. git apply --check clean against the audited tree.

5. Kernel references

sys/dev/raid/dpt/dpt_pci.c:134-143, :151-156; sys/dev/raid/dpt/dpt_scsi.c:1172-1204, :1235, :1356, :1370; sys/dev/raid/dpt/dpt.h:986.

Fix status (batch validation)

Applied with the 36 sibling fix.diffs of this batch in findings/poc/_batch41/all_fixes.patch; single in-guest make -j6 nativekernel KERNCONF=X86_64_GENERIC completed RC=0 with zero errors under -Werror (full log: findings/poc/_batch41/fix_build8.log). Behavior A/B intentionally skipped for this Info-tier item.