# 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.