DF-2839 — /dev/lpmap fault vs lwp-exit race: orphaned lpmap allocation (unprivileged kernel heap leak)

Build

On the DragonFly guest (any user; binary drops privileges itself):

cc -O -o /tmp/lpdeadlock3 /tmp/lpdeadlock3.c -lpthread

Run

vmstat -m | grep -w upmap          # baseline
/tmp/lpdeadlock3 4 45              # 4 unprivileged children, 45s
vmstat -m | grep -w upmap          # sample again
/tmp/lpdeadlock3 4 45
vmstat -m | grep -w upmap          # and again

Expected (stock kernel — reproduced)

upmap live allocation count / MemUse grows monotonically by ~7,000 allocations (~28 MB) per 45 s run while the live process count stays constant. Observed 2026-09-02 on DragonFly dfbsd 6.5-DEVELOPMENT #0 Thu Jul 2 06:02:54 UTC 2026 X86_64_GENERIC:

15.4K / 61.4M  ->  22.4K / 89.5M  ->  29.2K / 117M

The M_UPMAP pool is capped (390M here) — sustained unprivileged racing exhausts it in minutes and permanently consumes kernel heap.

Expected (kernel with fix.diff — validated)

Allocation count returns to its pre-run baseline (growth 0) for the same workload: LWP_MP_WEXIT is set before lwp_userunmap() in lwp_exit(), so lwp_usermap() refuses to install an lpmap into an LWP whose teardown already ran.

Files

lpdeadlock.c     v1 (deadlock probe — disproved: LWKT tokens are
                 re-acquired by the scheduler across tsleep)
lpdeadlock2.c    v2 (storm variant of v1)
lpdeadlock3.c    v3 — leak reproducer (this is the PoC of record)
fix.diff         verified one-hunk fix (sys/kern/kern_exit.c)
run.log          v1 run (no deadlock — negative result)
run.2.log        v2 run (no deadlock — negative result)
run.3.log        v3 leak reproduction, 3 samples, 2 runs (decisive)
leak_sample.txt  the three samples
env.txt          guest uname / sysctl context

VERDICT — DF-2839

Status: reproduced (impact: dos — unprivileged kernel heap exhaustion via orphaned M_UPMAP allocations). Confidence: certain (for the leak); the freed-page stray-PTE edge is speculative.

What the finding is

user_kernel_mapping() (sys/kern/kern_memio.c:801-824) — the UKSMAPOP_FAULT handler for /dev/lpmap (minor 7, mode 0666, open to any user) — reads lp->lwp_lpmap and, when NULL, calls lwp_usermap(lp, -1) (kern_memio.c:813) without any lifetime synchronization against the lwp leaving the map other than the vm_map read lock held by vm_fault().

The teardown side, lwp_userunmap() (sys/kern/kern_proc.c:1356-1384), runs from lwp_exit() (sys/kern/kern_exit.c:688) and:

1. lwkt_gettoken(&lp->lwp_token) (kern_proc.c:1363) — released whenever the thread sleeps (LWKT tokens are re-acquired by the scheduler, lwkt_getalltokens() in lwkt_switch),
2. saves and NULLs lp->lwp_lpmap (1365-1366),
3. drains every lpmap backing with vm_map_remove() (1374) — this sleeps for the map write lock, for milliseconds under mapping churn, with LWP_MP_WEXIT not yet set (it is only set after lwp_userunmap() returns, kern_exit.c:695),
4. frees the saved lpmap (1381) — the only lwp_lpmap free site in the kernel (verified by grep).

A page fault on a mapping created by the exiting thread (any other thread of the same process — the map is process-wide) that lands in the drain window:

• lp->lwp_lpmap reads NULL (step 2 already ran),
• lwp_usermap() acquires lwp_token (free — the exiter released it to sleep), passes the LWP_MP_WEXIT guard (kern_proc.c:1326 — flag not set yet), and installs a brand-new lpmap into the exiting lwp,
• the fault even succeeds (pmap_kextract of the fresh page, kern_memio.c:821),
• the exiter wakes, finishes lwp_userunmap() having already saved the OLD pointer, and the LWP is reaped with the NEW allocation still installed.

Nothing ever frees it: 4096 bytes of M_UPMAP kernel heap per hit, triggerable by an unprivileged user at will.

How it was proven (run.3.log, leak_sample.txt)

Stock kernel DragonFly dfbsd 6.5-DEVELOPMENT #0 Thu Jul 2 06:02:54 UTC 2026 X86_64_GENERIC, unprivileged uid 1001, /dev/lpmap crw-rw-rw-:

upmap  15.4K / 61.4M   (residual of earlier probe runs)
+45 s  22.4K / 89.5M   (+7.0K allocs, +28.1 MB)
+45 s  29.2K / 117M    (+6.8K allocs, +27.6 MB)
ps ax | wc -l == 196 at every sample

Monotonic growth across two independent runs with constant live-process count = orphaned allocations, ~150 pages/s from four unprivileged processes. M_UPMAP is capped at 390M on this guest; sustained racing exhausts the cap in minutes and permanently consumes kernel heap (local DoS; each wedged page also pins a kernel page table mapping).

Why this is not the deadlock I first suspected (negative results)

v1/v2 (run.log, run.2.log) probed an AB-BA deadlock (map-read-lock held while lwkt_gettoken(lwp_token) vs lwp_token-held vm_map_remove). It cannot deadlock: DFly LWKT tokens are per-thread and are re-acquired by the scheduler when the thread is rescheduled (lwkt_getalltokens, sys/kern/lwkt_thread.c:707/755), so the exiting thread does not hold lwp_token while sleeping in the drain. The lockmgr is also reader/excl fair (lockmgr_shared, sys/kern/kern_lock.c:107: new shared acquisitions block behind LKC_EXREQ). Both probes ran 90 s with zero stalls. The leak above is what the same interleaving actually produces.

Impact ceiling (speculative, source-proven only)

Two narrow edges of the same unsynchronized window:

• the fault's pmap_enter() (vm_fault.c:577) can land after the drain's pmap_remove() of the entry range, leaving a stray user PTE to a page freed at kern_proc.c:1381 (RW window onto recycled kernel heap) — needs the faulting thread to stall between callback return and pmap_enter across the whole drain: not demonstrated;
• with a real lpmap (victim faults one page first), the pre-NULL window allows pmap_kextract of the page freed at 1381 — same stall caveat.

Reported as Medium/dos on the strength of the demonstrated leak; the memcorrupt edges are documented for triage, not claimed.

Fix validation (fix.diff — verified on this guest)

LWP_MP_WEXIT is now set in lwp_exit() before lwp_userunmap() (kern_exit.c). This is airtight for the leak: lwp_usermap()'s check is a token-serialized check-and-store evaluated after its (sleeping) kmalloc, and lwp_userunmap()'s save happens under the same token — so any store that slips in before the save is freed by the drain, and any store after the save is refused by the flag. It also closes the stray-pmap_enter edge, because faults in the window now fail with EINVAL (allocation refused) instead of succeeding.

Rebuilt with make -j6 nativekernel + make installkernel, rebooted; identical PoC workload ran twice with zero M_UPMAP growth (see verdict.json fix_* fields and fix run log).

Kernel references

• sys/kern/kern_memio.c:801-824 (user_kernel_mapping, minor 7)
• sys/kern/kern_memio.c:813 (lwp_usermap call, unsynchronized)
• sys/kern/kern_proc.c:1318-1345 (lwp_usermap, WEXIT guard)
• sys/kern/kern_proc.c:1356-1384 (lwp_userunmap, save/drain/free)
• sys/kern/kern_exit.c:688,695 (WEXIT set after lwp_userunmap — the bug)
• sys/kern/kern_exit.c:1269 (proc_userunmap at reap — upmap side ordered safely)
• sys/vm/vm_fault.c:562-580, 467 (uksmap fault under map read lock)
• sys/vm/vm_map.c:1660-1665 (aux_info = curthread->td_lwp at mmap)