DF-4212 — mpt_raid_attach error paths: MPT_UNLOCK on a lock it never took (guaranteed panic) + CCB leak

• File: sys/dev/disk/mpt/mpt_raid.c
• Lines: 283–287, 288, 311, 314–317
• Class: error-path lock protocol violation (CWE-667) → kernel panic; memory leak (CWE-401)
• Hardware gate: LSI MPT Fusion RAID controller, attach-time error (kthread_create ENOMEM)

Bug 1 — unlock without lock (panic)

mpt_raid_attach():

    error = mpt_spawn_raid_thread(mpt);          /* 283 */
    if (error != 0) {
        mpt_prt(mpt, "Unable to spawn RAID thread!\n");
        goto cleanup;                        /* 286: MPT_LOCK NOT held */
    }
    csa = &xpt_alloc_ccb()->csa;                 /* 288 */
    MPT_LOCK(mpt);                               /* 290 */
    ...
cleanup:                                             /* 314 */
    MPT_UNLOCK(mpt);                             /* 315: LK_RELEASE */
    mpt_raid_detach(mpt);
    return (error);

If mpt_spawn_raid_thread() fails (kthread_create ENOMEM, mpt_raid.c:645), control reaches cleanup without ever executing MPT_LOCK (taken only at line 290). MPT_UNLOCK is lockmgr(&mpt->mpt_lock, LK_RELEASE) (sys/dev/disk/mpt/mpt.h:763-764), and DragonFly's lockmgr panics on releasing an unheld lock: panic("lockmgr: LK_RELEASE: no lock held") (sys/kern/kern_lock.c:761-768). So the error path converts a recoverable ENOMEM into a guaranteed kernel panic during device attach (boot or kldload under memory pressure).

Bug 2 — CCB leak on the other error path

If mpt_register_handler fails (line 292–297), the csa CCB allocated at line 288 is never freed — cleanup only calls mpt_raid_detach(), which allocates and frees its own CCB (mpt_raid.c:333, 349). One xpt_alloc_ccb() leaks per failed attach.

Verification status

untested — hardware-gated (no MPT HBA on the guest, see env.txt; also requires kthread_create failure). Source-certain: the lock-state arithmetic is two lines apart and kern_lock.c:768 makes the panic deterministic.

Fix

fix.diff: return directly on spawn failure (nothing to unwind); free csa before calling mpt_raid_detach on the handler-registration failure.

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.