VERDICT — DF-2782: sys_mq_open NULL-pointer lockmgr panic (race-gated limit path)

Status: REPRODUCED · impact: panic · confidence: certain

What was proven on the guest (stock kernel, build #0)

/tmp/limit_race 300 (8 threads, barrier-synchronized from a count of 511): kernel panicked mid-run — serial console (panic.txt):

Fatal trap 12: page fault while in kernel mode
current process = 842
kernel: type 12 trap, code=0
Stopped at      lockmgr_release+0x11:  movq 0x8(%rdi),%rsi

ssh dropped mid-run (Connection ... closed by remote host), vm.sh status ⇒ down — the honest panic signature.

Root cause path: two (or more) threads pass the early unlocked limit check at sys_mqueue.c:452 while p_mqueue_cnt == 511; the first completes its open (count 512); the second reaches the under-lock check at :577, takes the error = EMFILE; goto exit; branch — but mq is still NULL in this branch (mq = mqueue_lookup(name) returned NULL; mq = mq_new happens only at :583, AFTER the check) — and the shared exit label at :595-596 executes lockmgr(&mq->mq_mtx, LK_RELEASE) on a NULL-derived address (~0x100) → page fault → panic.

Corroboration: the identical crash signature was independently produced when a rejected first-version DF-2781 fix diff introduced a goto exit with mq == NULL at the same site (fixiter1_context.txt) — same trap, same instruction — confirming the exit-path shape is the hazard and that the stock :577 check has exactly that shape.

Fix validation (patched kernel, build #1 04:57)

fix.diff: guard the shared release (if (mq)) — mq is non-NULL on every other path reaching the label. Patched kernel: the same PoC ran 300 rounds × 8 threads ("round 299 survived ... survived 300 rounds without the panic"), guest up (fix_validation.log).

fix_status: fixed (fix_baseline_reproduced=1, fix_patched_reproduced=0).