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