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