DF-2673 — recursive vm_map_lock panic in vm_map_growstack() under MAP_WIREFUTURE

What

vm_map_growstack() upgrades to the exclusive map lock (sys/vm/vm_map.c:4228-4233), inserts the stack growth, and then — if mlockall(MCL_FUTURE) set MAP_WIREFUTURE — calls vm_map_user_wiring() at sys/vm/vm_map.c:4274-4278 while still holding that exclusive lock. vm_map_user_wiring() immediately does vm_map_lock(map) (sys/vm/vm_map.c:2594) → lockmgr(LK_EXCLUSIVE) recursion without LK_CANRECURSE → panic("lockmgr: locking against myself") (sys/kern/kern_lock.c:310).

Impact

Privileged (mlockall requires SYSCAP_RESTRICTEDROOT) local kernel panic / denial of service. Every stack growth in an MCL_FUTURE process panics.

Reproduce

./build.sh            # cc -O2 -o /tmp/grow_wirefuture grow_wirefuture.c
                      # RUN AS ROOT
/tmp/grow_wirefuture  # mlockall(MCL_FUTURE); fault 8MB below the stack

Expected (observed): guest dies in DDB with

panic: lockmgr: locking against myself
lockmgr_exclusive() at lockmgr_exclusive+0x3e0
lockmgr_exclusive() at lockmgr_exclusive+0x3e0
vm_map_user_wiring() at vm_map_user_wiring+0x3a
vm_map_grow_stack() at vm_map_growstack+0x399
vm_fault() at vm_fault+0x11f
trap_pfault() at trap_pfault+0x209

Fix

fix.diff — save the grown range and perform the wiring after the map lock is released (same pattern vm_mmap.c:1510-1511 already uses).

DF-2673 VERDICT — REPRODUCED (kernel panic), fix validated

Question

Does a fault below the stack in a process with mlockall(MCL_FUTURE) panic the kernel?

Root cause (path:line)

• vm_map_growstack() upgrades to the exclusive map lock at sys/vm/vm_map.c:4228-4233 (vm_map_lock_upgrade / Retry with use_read_lock = 0).
• After a successful growth insert it calls, at sys/vm/vm_map.c:4274-4278, vm_map_user_wiring(map, ...) — which begins with vm_map_lock(map) (sys/vm/vm_map.c:2594) = lockmgr(LK_EXCLUSIVE).
• The map lock is initialized without LK_CANRECURSE (sys/vm/vm_map.c:647, lockinit(&map->lock, "vm_maplk", ..., 0)), so the recursive acquisition panics: panic("lockmgr: locking against myself") (sys/kern/kern_lock.c:310).

Reproduction (run as root — mlockall needs SYSCAP_RESTRICTEDROOT)

Observed serial-console panic (panic.txt):

panic: lockmgr: locking against myself
cpuid = 1
lockmgr_exclusive() at lockmgr_exclusive+0x3e0
lockmgr_exclusive() at lockmgr_exclusive+0x3e0
vm_map_user_wiring() at vm_map_user_wiring+0x3a
vm_map_grow_stack() at vm_map_growstack+0x399
vm_fault() at vm_fault+0x11f
trap_pfault() at trap_pfault+0x209
Debugger("panic")

The backtrace is exactly the statically-traced path (guest down in DDB; vm.sh status → down). Reproduced on the first attempt — deterministic, not a race.

Impact: privileged local DoS (panic). Low severity only because mlockall(MCL_FUTURE) requires root; note a root process that sets MCL_FUTURE then drops privileges keeps the panic armed.

Fix validation

fix.diff records the grown range and calls vm_map_user_wiring() after vm_map_unlock() (same pattern as sys/vm/vm_mmap.c:1510-1511). On the patched kernel the PoC completes without panicking and the grown range is wired (see fix run in run.log).

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.