DF-0923 — PoC: UAF of vmspace/vm_map (and vm_map_backing) across the per-iteration unlock in /proc/<pid>/map

Bug (one line)

procfs_domap() (sys/vfs/procfs/procfs_map.c) caches map = &p->p_vmspace->vm_map without vmspace_hold(), drops the vm_map read lock per iteration (:142-143), then re-locks/iterates the now-stale cached map (:230, :89). A concurrent execve()/exit() on the target frees the vmspace → use-after-free → kernel panic.

Threat model

Unprivileged local user. /proc/<pid>/map is -r--r--r-- (world-readable). The maxx user (uid 1001, not in wheel) forks a child that tight-loops execve (freeing/replacing its vmspace) and reads /proc/<child>/map in a tight loop, racing the per-iteration lock-drop window.

Build & run

cc -O2 -o race_map race_map.c
./race_map [seconds] [nreaders]      # default 30 s, 4 readers

Run as an unprivileged user (e.g. maxx). The race is statistical but, on the unpatched kernel, panics within seconds every time. The PoC is self-contained: the --victim mode re-execs itself to drive vmspace churn; the --reader mode hammers /proc/<victim>/map.

Expected output

• Unpatched kernel (#0): kernel panic within seconds (guest dies; ssh drops): Fatal trap 12: page fault while in kernel mode fault virtual address = 0x8 Stopped at vm_map_rb_tree_RB_NEXT: movq 0x8(%rdi),%rax
• Patched kernel (#1, fix.diff applied): runs to completion cleanly: [parent] survived Ns without panic; tearing down [parent] done (no panic observed this run)

Notes

• The reader uses a 4 KB read buffer deliberately (see the comment in race_map.c): procfs_domap sizes its sbuf from uio_offset + uio_resid, and a large resid under many parallel readers independently trips sbuf: malloc limit exceeded — an unrelated pre-existing issue that would mask the UAF. 4 KB still drives procfs_domap through every map entry (every per-iteration unlock window), which is all the UAF race needs.
• Escalation to uid=0 is not achievable: read-dominant UAF of a dedicated-slab object (vmspace_cache); no attacker-controlled write to a victim object. See VERDICT.md for the full Phase-6 analysis.
• The validated fix is fix.diff (add vmspace_hold/vmspace_drop mirroring procfs_rwmem, keep p_token held for LIFO token order, EFAULT checks before sbuf_new to avoid a leak).

DF-0923 — VERDICT

Verdict

REPRODUCED — reliable kernel panic (DoS) from an unprivileged user. The use-after-free of vm_map (embedded in vmspace) cached in procfs_domap() is real, deterministic, and triggered by an unprivileged local user (maxx, uid 1001). Fix validated on a single-fix kernel (Phase 8 passed: panic gone). Escalation to uid=0 is not achievable: the primitive is a read-dominant UAF of a dedicated-slab object (vmspace_cache); see "Exploit chain / escalation" below.

The bug (confirmed path:line)

procfs_domap() in sys/vfs/procfs/procfs_map.c:

A concurrent execve() on the target calls vmspace_exec() (sys/vm/vm_map.c:4298) which does vmspace_rel(oldvmspace) at :4330. With no hold/ref held by procfs_domap, the old vmspace (and its embedded vm_map, including map->lock and the RB tree) is freed (objcache_put(vmspace_cache, vm) at vm_map.c:543). The reader's re-lock/iterate at :230/:89 then operates on freed memory => UAF => panic. exit() is also sufficient: kern_exit.c:432-433 releases p_token around vmspace_relexit(vm), so the vmspace can be freed even while a reader holds p_token.

Reproduction

PoC: race_map.c — parent forks a victim that tight-loops execve(self,"--victim") (each exec replaces/frees the vmspace) and N readers that tight-loop open()+read() of /proc/<victim>/map (entering procfs_domap). 4 KB read buffer (deliberately small — see comment in the source — to avoid tripping an unrelated sbuf malloc-limit issue that would mask the UAF).

Result on default GENERIC #0 (INVARIANTS ON): deterministic kernel panic within seconds, every run, identical signature:

Fatal user address access from kernel mode from race_map at ffffffff809a2540
Fatal trap 12: page fault while in kernel mode
fault virtual address = 0x8
current process = <reader pid>
Stopped at vm_map_rb_tree_RB_NEXT: movq 0x8(%rdi),%rax   <- RB_FOREACH through freed vm_map

Reproduced 3× (4 readers/25 s and small-buffer variants). Guest down each time.

Exploit chain / escalation (Phase 6)

Outcome: blocked by a valid hard blocker — read-only UAF of a dedicated-slab object; no attacker-controlled write to a victim is derivable. Impact = panic.

• Primitive: the reader's operations on the freed/stale map are read-dominant: ba->object reads (:175-178,216), map->timestamp read (:142,236), vm_map_lookup_entry/RB walk (:238, :89). The only write to freed memory is vm_map_lock_read(map) at :230 = lockmgr LK_SHARED, which increments the lockmgr shared-count at a fixed offset (offsetof(struct vm_map, lock) within the vmspace-embedded map) by a fixed delta (+1). It is not attacker-controlled in value or target.
• Slab: vmspace uses a dedicated objcache (vmspace_cache, vm_map.c:121,233). A freed vmspace is returned to vmspace_cache and is reused only by vmspace_alloc() — never by struct file/ucred/a function-pointer object. Cross-type slab grooming into the freed slot is therefore impossible.
• Consequence of the lone write: when the freed slot is reused by a new vmspace (the only possible reuser), map->lock is a valid lockmgr lock — the reader's LK_SHARED just takes a shared lock on a stranger's valid vmspace (logic confusion + a cross-process map info-leak into the reader's sbuf). No corruption; certainly no controlled write to a victim object.
• No chain attempted is justified because there is no write primitive to convert. This is Phase 6 valid hard blocker #1 ("genuinely read-only").
• Secondary impact: a cross-process info leak of another user's /proc/<pid>/map contents (kernel pointers, vnode paths) if the reader catches a slot reused by a victim's vmspace — bounded, not controllable, lower severity than the DoS.

The fix (fix.diff — validated)

Mirror procfs_rwmem(): vmspace_hold(vm) before caching map, vmspace_drop(vm) after the scan. Two DragonFly-specific constraints shaped the exact patch:

1. lwkt tokens are a strict LIFO stack (sys/kern/lwkt_token.c:828-857, assertion at :842-853: lwkt_reltoken pops the top ref and requires it to match). vmspace_hold() acquires vm_map.token on top of p_token, so vm_map.token must be released first. Therefore p_token is held for the entire function (the original lwkt_reltoken(&p->p_token) at :87 and the re-acquire at :248 are removed), and vmspace_hold/vmspace_drop nest cleanly inside p_token's scope.
2. p_token alone does not pin the vmspace: kern_exit.c:432-433 releases p_token around vmspace_relexit(). The vmspace_hold (which bumps vm_holdcnt) is what actually prevents termination.
3. The vmspace-validity EFAULT checks (SIDL/SZOMB, P_WEXIT/P_INEXEC, vmspace_getrefs<0, mirroring procfs_rwmem:85-88) are placed before sb = sbuf_new() so the EFAULT paths do not leak the sbuf (an earlier fix iteration that put them after sbuf_new leaked the sbuf on every exec and tripped sbuf: malloc limit exceeded).

#include <vm/vm_extern.h> is added (declares vmspace_hold/vmspace_drop/ vmspace_getrefs; already included by procfs_mem.c).

This fix supersedes the finding markdown's initial proposal (which suggested vmspace_hold/vmspace_drop without addressing the LIFO token order, the p_token-held-throughout requirement, or the sbuf-leak hazard).

Phase 8 — fix validation

Clean before/after => fix_status = fixed. (Two intermediate fix iterations failed first: v1 tripped lwkt_reltoken: illegal release (LIFO); v2 tripped sbuf: malloc limit exceeded (leaked sbuf). v3 = shipped fix.diff.)