DF-2834 evidence pack — unbounded vmspace_create kernel-memory exhaustion

File: sys/vm/vm_vmspace.c:146-201 (sys_vmspace_create) Severity: Medium (CWE-770) — unprivileged local DoS, gated on vm.vkernel_enable=1

What was verified

1. No cap exists on the path (static + dynamic): - sys_vmspace_create (sys/vm/vm_vmspace.c:146-201) consults no rlimit, no priv_check, no counter. The only gate is vkernel_enable (sys/vm/vm_vmspace.c:155). Contrast: mmap entries ARE capped by vm.max_proc_mmap (1000000 on this guest). - Empirical: 120,000 live vmspaces created by ONE unprivileged (uid 65534) process in 6.9 seconds, zero failures.

2. Per-iteration cost (line-accurate): - kmalloc(sizeof(struct vmspace_entry)) — sys/vm/vm_vmspace.c:182 - vmspace_alloc() — sys/vm/vm_vmspace.c:183 → sys/vm/vm_map.c:309-340, objcache vmspace_cache (sys/vm/vm_map.c:233) - pmap_pinit() — sys/platform/pc64/x86_64/pmap.c:2347

   • 8192 bytes pageable kernel KVA: kmem_alloc_pageable(kernel_map, PAGE_SIZE * 2, VM_SUBSYS_PML4) (pmap.c:2368-2370)
   • 1 WIRED PML4 vm_page: pmap_allocpte(pmap_pml4_pindex()) (pmap.c:2376-2380) → vm_page_wire(m) (pmap.c:2757) — the page is wired and therefore unswappable/unreclaimable
   • pmap_pinit2() (sys/vm/vm_vmspace.c:187) is a NO-OP on x86_64 (pmap.c:2509-2512) — refinement of the finding text, which listed it as a cost contributor
   • Measured totals: 2.374-2.376 wired pages per create (9.7 KB) and 9752 bytes KVA per create (cold), perfectly linear.

3. Growth is unswappable while the vmspaces are live — wired pages are not reclaimable by the page daemon; the only releases are vmspace_destroy or process exit (vkernel_exit → rb_vmspace_delete).

4. Exhaustion extrapolation (NOT executed — single-tenant guest): - guest physmem 4,257,873,920 B = 1,039,519 pages - measured rate 17,350 creates/s (120k in 6.915 s) - quiescent wirable pool (wire+free) ≈ 992,529 pages → ≈ 418,000 creates → ≈ 24 seconds for one unprivileged process to wire all 4 GB - failure mode at exhaustion: vm_page_alloc(VM_ALLOC_NORMAL) inside pmap_allocpte (pmap.c:2751-2756) fails → vm_wait(0) loop; wired pages can never satisfy the wait → every M_WAITOK allocator system-wide stalls → hard wedge. No clean error return exists on this path.

Files

• vmsp_grow.c — main PoC: unpriv create loop with wire/KVA/free sampling
• vmsp_cap.c — fix-validation helper: cap hit / destroy-frees-slot check
• run.log — stock-kernel runs (20k cold, 20k warm-reuse, 120k capped)
• run.fixed.log — patched-kernel A/B (cap, per-proc, raised-cap legit use)
• fix.diff — the verified fix (cap + ABI guards), applied only in the guest /usr/src scratch copy, never to the audit tree
• build.log — full compiler output (warning-free)
• env.txt — guest/kernel/compiler state
• VERDICT.md — full narrative and math
• manifest.json, verdict.json — machine-readable results

Reproduce

build.sh                 # cc -O2 -Wall -o /tmp/vmsp_grow vmsp_grow.c
run.sh                   # enable sysctl, capped 120k unpriv run, restore

Success criterion (stock kernel): # DONE created=120000 ... grow_exit=0 with linear wire growth ~2.37 pages/iteration and zero failures.

VERDICT — DF-2834 (unbounded vmspace_create kernel-memory exhaustion)

status: reproduced / impact: dos / confidence: certain

Guest: DragonFly 6.5-DEVELOPMENT #0 (stock INVARIANTS kernel, X86_64_GENERIC), QEMU/KVM 4GB / 6 vcpu. All runs 2026-10-20 UTC.

1. Reachability and the no-cap claim

sys_vmspace_create (sys/vm/vm_vmspace.c:146-201) is a plain syscall (SYS #486) with no privilege check of any kind. The ONLY gate is vkernel_enable at sys/vm/vm_vmspace.c:155 (vm.vkernel_enable, root sysctl, default 0). With it set to 1 — the documented operating state of any machine that hosts virtual kernels — any local user can create vmspaces without limit:

• statically: no rlimit (lim_*), no priv_check, no counter, no sysctl cap anywhere in the function; nothing else in the kernel counts p_vkernel vmspaces;
• empirically: 120,000 live vmspaces in one unprivileged process (uid 65534), zero failures, 6.9 seconds (run.log, PRE3..120000 block). For contrast, mmap entries per proc are capped (vm.max_proc_mmap = 1000000); no analogous knob existed for vmspaces.

2. Per-iteration cost, line-accurate

Each successful create, held until vmspace_destroy or process exit:

The finding text listed pmap_pinit2 among the cost contributors; on x86_64 it is an empty function (refinement, not a contradiction — the substance of the cost chain is confirmed).

3. Measured growth (stock kernel)

Three runs, ids 0x10000000+i, sampling vm.stats.vm.v_wire_count, vm.kvm_free, vm.stats.vm.v_free_count:

() warm run reused objcache-retained objects (see §5); wire slope stays ~2.37 pages/create. Growth is linear (run 1 vs run 3 slope delta 0.1%). Rate: 17,350 creates/s* sustained.

120,000 live vmspaces = 431,414 wired pages observed mid-run (~1.68 GB wired held by one unprivileged process). Guest stayed healthy (load 0.18 after).

4. Exhaustion extrapolation — NOT executed (single-tenant guest)

• total physical pages: 4,257,873,920 / 4096 = 1,039,519
• quiescent wirable pool (wire 143,045 + free 849,484) = 992,529 pages
• creates needed: 992,529 / 2.374 ≈ 418,000
• time: 418,000 / 17,350 ≈ 24 seconds for one unprivileged process to wire the entire 4 GB of this guest (pageout cannot help: wired pages are unswappable).

Failure mode at the wall: vm_page_alloc(VM_ALLOC_NORMAL) inside pmap_allocpte (pmap.c:2751-2756) fails → vm_wait(0) loop; because the exhaustion is in WIRED memory the wait can never be satisfied, and every M_WAITOK allocation system-wide blocks → hard hang, no clean error. The path offers no error return before that point (kmalloc(M_WAITOK) at vm_vmspace.c:165/:182, vmspace_alloc(M_WAITOK)). This is the panic-free-but-wedge class: RUN timeout + unresponsive guest would be the observed artifact if executed; deliberately not driven to that state on the shared audit guest per policy — the linear rate + totals above are the honest proof of the exhaustion primitive.

5. Post-exit reclamation (hygiene + not-a-permanent-leak)

Process exit (vkernel_exit sys/vm/vm_vmspace.c:773-805 → rb_vmspace_delete → vmspace_entry_delete) reclaims live vmspace memory: run 3 dropped wire from 431,414 → 154,535 within 3 s of exit. Some memory stays CACHED (objcache magazines retain vmspace objects with their pmap — see vm_map.c:244 comment; vmstat -m showed 390 MB M_VKERNEL retained right after exit) — run 2 proved this cache is REUSED, not leaked (Δkvm_free ≈ 0 for the first 15,000 warm creates). The DoS primitive is the LIVE pinned set, which the attacker controls the duration of.

6. Fix validation (A/B on patched kernel)

Patch: fix.diff — adds nvmspaces to struct vkernel_proc (sys/sys/vkernel.h), vm.max_vkernel_vmspaces sysctl (default 64), cap checked+incremented under vkp->token in the same critical section as the RB insert (mirroring the EEXIST unwind), decremented in vmspace_entry_delete under the token. Also the DF-2835 EINVAL guards.

Built with make nativekernel KERNCONF=X86_64_GENERIC in the guest scratch /usr/src (6.1 min, warning-free), installed, rebooted into #1: Tue Oct 20 11:55:22 UTC 2026. sysctl vm.max_vkernel_vmspaces: 64 present.

Legitimate vkernel workloads (vkernel userland creates one vmspace per emulated process; typical counts are tens) sit far below 64; operators running huge vkernels raise one sysctl. Not boot-tested end-to-end (vkernel-in-vkernel out of scope for this guest) — reasoned from vmspace_create call sites.

Baseline vs patched: stock = unbounded linear growth, no error; patched = clean ETOOMANYREFS at the cap, legitimate paths intact.

7. Team directive: privesc?

NOT privesc. There is no uid=0 route — the primitive is resource exhaustion (impact dos). It is gated on vm.vkernel_enable=1, a root tunable that defaults to 0, so default-config machines return EOPNOTSUPP to unprivileged callers. On vkernel-hosting machines (tunable = 1, the supported configuration) any local unprivileged user can wedge the box in seconds. Medium severity is the correct rating; the finding stands as filed.

8. Guest hygiene

vm.vkernel_enable restored to 0 immediately after each stock-kernel run and after the fixed-kernel legs; guest vm.sh reset with-src performed at the end (patched kernel replaced by the clean snapshot kernel); guest_dirty = 0.

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.