lockmgr_release() multi-count blind decrement loses the grant/wakeup transition under concurrent LK_KERNTHREAD release (lost wakeup: waiter sleeps on a free lock)

DF-2750 — lockmgr_release() multi-count blind decrement: lost wakeup under concurrent LK_KERNTHREAD release ============================================================================

1. WHAT WAS FOUND (code defect, sys/kern/kern_lock.c)

lockmgr_release() handles the release of an exclusively-held lock with three validated single-count cases followed by a "multiple exclusive counts" else-branch:

• kern_lock.c:781-813 (XMASK==1, no UPREQ/EXREQ) -> clears EXREQ2 and CANCEL, pre-sets LKC_SHARED, wakeup(lkp) if waiters
• kern_lock.c:814-841 (XMASK==1 + UPREQ) -> grants upgrade, wakeup
• kern_lock.c:842-873 (XMASK==1 + EXREQ) -> grants excl, wakeup
• kern_lock.c:874-886 (else: XMASK>=2) -> *** BLIND *** decrement

The else-branch does:

    count = atomic_fetchadd_long(&lkp->lk_count, -1);

based on a `count' value that was read non-atomically at function entry (kern_lock.c:753). There is no re-validation.

The lock-holder check at kern_lock.c:774-775 permits ANY thread to release when lk_lockholder == LK_KERNTHREAD — this is the buffer-cache biodone hand-off protocol (BUF_KERNPROC, sys/sys/buf2.h:101-109), used by ~30 consumers (vfs_cluster.c, hammer/hammer2 io, nvme, dm, ccd, nfs, swap pager, ...).

Consequence: two threads releasing concurrently (both legal holders via KERNTHREAD) that both read LKC_XMASK == 2 drive the count 2 -> 0 with NEITHER thread executing a single-count case. In that transition:

• no wakeup(lkp) is issued at all;
• LKC_EXREQ2 is left set (stranded);
• LKC_CANCEL is not cleared;
• LKC_SHARED is not pre-set.

Any thread parked in lockmgr_exclusive()'s EXREQ2 tsleep (set at kern_lock.c:365-385 when the lock is exclusively held) now sleeps on a lock that is completely FREE (count == LKC_EXREQ2 only). It remains asleep indefinitely — until unrelated traffic on the same lock instance happens to issue a wakeup (e.g. a later acquire+release cycle). For a buffer lock that typically means the I/O strategy blocked in BUF_LOCK hangs (unkillable if the sleep has no PCATCH/TIMO, which buffer locks do not).

A serialized double-release (the common case) is caught loudly by the panic at kern_lock.c:767-768 ("LK_RELEASE: no lock held") — only the exactly-concurrent window wedges silently.

Reachability today: requires a consumer that (a) recurses an exclusive lockmgr lock to XMASK>=2, (b) transfers it to LK_KERNTHREAD, and (c) has two threads release it concurrently — i.e. an upstream hand-off bug (no in-tree consumer currently does this; there is no BUF_RECURSE macro and the biodone hand-off releases exactly once). The defect is a robustness/liveness hole in the core primitive: it converts a future consumer race into a silent permanent hang instead of either a clean state transition or the existing loud panic. Class: local DoS (hang) in the making; defense-in-depth for the lockmgr core.

2. REPRODUCTION (full logs in env.txt / run.log)

Harness: findings/poc/DF-2750/lkmc.c (KLD). Deterministically stages the exact precondition each round:

lockinit(&lk, "lkmc", 0, LK_CANRECURSE); lockmgr(&lk, LK_EXCLUSIVE); / XMASK = 1 / lockmgr(&lk, LK_EXCLUSIVE); / XMASK = 2 (recursive) / lockmgr_kernproc(&lk); / holder = KERNTHREAD / [waiter thread]: lockmgr(&lk, LK_EXCLUSIVE); / parks on EXREQ2 /

then releases two lwkt threads pinned to cpu0/cpu1 from a shared spin barrier so both enter lockmgr_release() within nanoseconds, each reading count == XMASK(2)|EXREQ2 at entry.

HIT = after both releases complete: lk_count == 0x08000000 (LKC_EXREQ2 only, no counts) AND the waiter still asleep (revived only by the driver's manual wakeup()).

Guest: DragonFly 6.5-DEVELOPMENT, QEMU/KVM, 6 vCPUs, stock INVARIANTS kernel #0 (Thu Jul 2 2026).

RESULTS (stock kernel, 20000 rounds/run): 19750, 19756, 19617 hits (v3 harness; 98.1-98.8% hit rate) 15857, 19739, 19647, 19760 hits (v2 harness; identical staged race) every hit: bad_count == 0x08000000, healed == hits (waiter never self-completed), stuck=0, guest fully healthy after each run.

The lost wakeup is therefore 100% reproducible at the staged race rate of ~98%; it is not a rare cosmic-ray window.

3. FIX (fix.diff) AND VALIDATION

Convert the blind decrement into a validated fcmpset retry:

    ncount = count - 1;
    if (atomic_fcmpset_64(&lkp->lk_count, &count, ncount)) {
            if (lkp->lk_lockholder != LK_KERNTHREAD)
                    COUNT(td, -1);
            break;
    }
    /* fcmpset failed, count reloaded: retry */

The outer for(;;) then re-evaluates with the fresh count; the loser of the race re-reads XMASK==1 and falls into the proper single-count case (grant + wakeup + EXREQ2/CANCEL clear + SHARED pre-set). XMASK can never again transition to 0 outside a single-count case. Uncontended behavior is identical (one fcmpset instead of one fetchadd; same COUNT).

Validated in-guest: fix.diff applied to /usr/src, kernel rebuilt with `make nativekernel KERNCONF=X86_64_GENERIC', installed, rebooted (#1). Same harness, same load:

fixed:  rounds=20000 hits=0   (x3, plus one v2-harness run and
                               1/100-round shakedown runs: hits=0)
stock:  rounds=20000 hits=~19700 (x3)

The previously-observed bad state (count == 0x08000000 with the waiter asleep) never occurs; the waiter completes on its own in 100% of 60000+ staged races. fix_status: fixed.

4. HONEST CAVEATS / DEVELOPMENT NOTES

• Impact ceiling: demonstrated impact is a hang of a kernel thread on a free lock (dos), not memory corruption. lk_count never underflows via this path (the else-branch is only entered with XMASK>=2, and n concurrent blind decrements from n can reach 0 but not wrap), so there is no count-corruption/privesc angle.
• In-tree reachability requires a future/racy consumer (see §1); the finding is filed as Low severity hardening of a core primitive, not as an exploitable-today vulnerability.
• Two guest deaths during harness development were caused by HARNESS thread-lifecycle flaws (stale per-invocation threads double-releasing a 2-count lock -> the existing "LK_RELEASE: no lock held" panic at kern_lock.c:767), not by the target defect; the final v3 harness (persistent, generation-safe threads + bounded spins + drain) ran all reported results with zero bail-outs (stuck=0) and a healthy guest.
• An unrelated QEMU/KVM artifact was observed: freshly created cpu-pinned lwkt threads occasionally take seconds to get first-scheduled on idle vCPUs. This caused earlier harness bail-outs (stuck=1/10/2) and is mitigated in v3 by persistent threads parked in 1-tick polling tsleeps.

5. VERDICT

reproduced: YES (deterministic staging, ~98% of staged races on stock kernel; zero on patched kernel). impact: dos (uninterruptible hang of a kernel thread on a free lock; real-world severity gated on a consumer that KERNPROC-transfers a recursive exclusive lock and double-releases it concurrently). confidence: certain (code path proven by direct state observation; root cause isolated to the single blind fetchadd; fix eliminates it exactly and only there).