# VERDICT — DF-4212

**status: untested (hardware-gated) · impact: panic (attach-time, OOM-gated) · confidence: certain (source)**

Not reproducible on the audit guest: no MPT Fusion HBA (env.txt), and the
trigger additionally needs `kthread_create()` to fail during attach.

Source proof:
- `MPT_LOCK` is taken at `mpt_raid.c:290`, *after* the spawn-failure `goto
  cleanup` at 283–287; `cleanup` (314–317) executes `MPT_UNLOCK`
  unconditionally.
- `MPT_LOCK/MPT_UNLOCK` are plain lockmgr EXCLUSIVE/RELEASE
  (`sys/dev/disk/mpt/mpt.h:763-764`), non-recursive, and DragonFly lockmgr
  hard-panics on `LK_RELEASE` with no lock held
  (`sys/kern/kern_lock.c:761-768`: `panic("lockmgr: LK_RELEASE: no lock held")`).
- CCB leak: `csa` allocated at `mpt_raid.c:288` is freed only at line 311 on
  the success path; the `goto cleanup` at 296 skips it, and
  `mpt_raid_detach` frees only its own CCB (`mpt_raid.c:333/349`).

Deterministic panic, but the precondition (attach-time kthread ENOMEM on a
machine with the RAID HBA) makes it Low severity. Fix is trivial and
low-risk; not runtime-validated (no hardware) → `fix_status: not_testable`.

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