DF-0032 — PoC

fdcopy() failure in fork1() permanently leaks the child struct proc, the system-wide nprocs counter, and the per-uid proc-count → local unprivileged system-wide fork-DoS (permanent until reboot). Severity Medium, CWE-401/772.

Status

REPRODUCED. See VERDICT.md for the full narrative and run.log for the decisive evidence.

The original fork_leak.c (mmap-pressure trigger) does not actually fire the bug — anonymous mmap consumes user VM, not the kernel M_FILEDESC malloc pool. exhaust.c is the working trigger (fd-table amplification).

The bug

fork1() charges nprocs++ (kern_fork.c:415) and chgproccnt++ (:421), kmalloc's p2 (:444), gives it uidpcpu/ucred/sigacts/textvp refs, and proc_add_allproc(p2) (:491) — all before fdcopy (:551). fdcopy is the only fd op that can fail (its struct filedesc kmalloc is M_WAITOK|M_ZERO|M_NULLOK at kern_descrip.c:2481-2486; fdinit/fdshare and the fd_files[] array are plain M_WAITOK). On failure fork1 does goto done (:552-554) and done: (:724-732) only releases tokens — no teardown of p2, no nprocs--, no chgproccnt--, no crfree/vrele. The SIDL orphan (no lwp, no parent — lwp_fork1 is at :674, after fdcopy) never reaches exit, so nprocs/chgproccnt are never decremented. Each failure permanently consumes one system-wide maxproc slot + one per-uid RLIMIT_NPROC slot.

When fdcopy actually fails

Its M_NULLOK kmalloc returns NULL when M_FILEDESC's per-type ks_limit is exceeded (kern_slaballoc.c:863-879). ks_limit = kmem_lim_size()/10 = min(physmem, KvaSize)/10 (~195 MB on a 2 GB guest). Each fork() on the RFFDG path charges M_FILEDESC for a copy of the parent's fd_files[] table — so growing the parent's fd table (via dup2 to high fds) amplifies the charge: ~260 children with ~15000-fd tables push M_FILEDESC to its limit, and the next fdcopy returns NULL → fork() returns ENOMEM → leak.

Build & run (unprivileged; disposable VM)

./build.sh        # cc -o exhaust exhaust.c  (and the other PoC binaries)
./run.sh          # runs exhaust, prints before/after malloc-type counts

Expected (bug present)

[!!!] ENOMEM from fork() -- fdcopy failure leak TRIGGERED at child 259
[*] summary: ok=259 eagain=51 enomem=705 other=0

After the run the proc (M_PROC) malloc-type Count is permanently elevated by ~705, while lwp and file_desc stay flat and ps ax|wc -l is unchanged (leaked SIDL orphans are invisible). Repeating across ~4–6 unprivileged uids exhausts maxproc and fork-DoSes the whole system (root included) until reboot.

Expected (bug fixed)

fork() no longer returns ENOMEM (the per-type limit is never reached because the failed allocations are rolled back, and/or M_FILEDESC no longer climbs because the leak is gone); proc Count returns to baseline after the run.

CAUTION

Each ./exhaust run permanently consumes ~700 system-wide maxproc slots until reboot. The guest is left ~18 % fork-exhausted after a single run. Run vm.sh reset to clean up. Do not loop across many uids on a host you are not prepared to reboot — that is the full DoS.

DF-0032 — VERDICT

Verdict: REPRODUCED. Real, unprivileged, local, system-wide fork-DoS (permanent until reboot). The reviewer-written PoC's trigger was wrong (mmap pressure), but the underlying bug is real and exploitable; a corrected trigger reproduces it reliably.

The bug (confirmed line-by-line in sys/)

In fork1() the irreversible steps happen before the only failing fd op:

nprocs is decremented only at kern_exit.c:1337 and chgproccnt only at kern_exit.c:1280 — both require a runnable/exiting lwp, which a SIDL orphan (no lwp, no parent linkage — lwp_fork1 is at :674, after fdcopy) never has. allproc scans skip SIDL procs, so ps/procstat never show them.

fdcopy is the only fd op that can fail because it is the only one whose struct filedesc kmalloc uses M_NULLOK:

sys/kern/kern_descrip.c:2481   newfdp = kmalloc(sizeof(struct filedesc),
sys/kern/kern_descrip.c:2482                    M_FILEDESC, M_WAITOK|M_ZERO|M_NULLOK);
sys/kern/kern_descrip.c:2483   if (newfdp == NULL) { *fpp = NULL; return (-1); }

fdinit (:2408) and fdshare use plain M_WAITOK (cannot fail), and fdcopy's own fd_files[] array (:2504) is M_WAITOK (no M_NULLOK), so it would panic on limit exhaustion rather than return NULL. The single clean failure mode is the M_NULLOK newfdp.

When does that M_NULLOK kmalloc actually return NULL?

kmalloc returns NULL with M_NULLOK when the per-type ks_limit is exceeded (kern_slaballoc.c:863-879):

ks_limit = kmem_lim_size() * 1MB / 10          (kern_slaballoc.c:371-372)
kmem_lim_size() = min(physmem, KvaSize)/1MB    (kern_slaballoc.c:255-263)

On this 2 GB guest: ks_limit(M_FILEDESC) = ~195 MB.

The original PoC tried to induce this with mmap+touch. That does not work: anonymous mmap consumes user VM and physical pages, not the kernel M_FILEDESC malloc pool. Live measurement showed M_FILEDESC unchanged (27 KB → 31 KB) across an mmap-pressure run. So the original PoC never triggers the bug — it only causes userland OOM.

The working trigger (fd-table amplification)

Each successful fork() on the RFFDG path calls fdcopy, which allocates a copy of the parent's fd_files[] table (kern_descrip.c:2504) under M_FILEDESC. A process that has grown its fd table large (via dup2 to high fds) therefore forces every child's fdcopy to charge M_FILEDESC for a large (~hundreds-of-KB) fd_files array. With a ~15000-entry fd table, each child costs ~700 KB of M_FILEDESC; ~260 such children push M_FILEDESC to its ~195 MB limit. At that point the next fdcopy's M_NULLOK newfdp kmalloc returns NULL → fdcopy returns -1 → fork1 does goto done → leak.

exhaust.c does exactly this and is fully unprivileged.

Evidence (all in this folder)

run.log is the decisive record. Highlights:

$ ./exhaust
[*] grew fd table to fd=14976 (fd_files[] ~234KB per fdcopy)
[!!!] ENOMEM from fork() -- fdcopy failure leak TRIGGERED at child 259
[*] summary: ok=259 eagain=51 enomem=705 other=0

Parallel root sampling during the slow variant caught the failure moment:

[t=57] file_desc=18.0M   proc=51
[t=59] file_desc=176M    proc=261     <- M_FILEDESC hit its ~195M ks_limit

The leak is confirmed by the kernel malloc-type counters (the leaked structs are never freed, so they persist):

lwp/file_desc being flat is the fingerprint that pins the leak to the exact point the code trace predicts: fdcopy failure (:551) after p2 was put on allproc (:491) but before lwp_fork1 (:674). If the leak were anywhere else, one of those counters would move.

System-wide impact (DoS demonstrated)

nprocs is a global counter; the leaked slots reduce fork capacity for every user, including root. Because the per-uid chgproccnt is also leaked (never decremented), one unprivileged uid can permanently burn ~700–1000 system-wide maxproc slots before self-capping at its own RLIMIT_NPROC. ~4–6 unprivileged uids exhaust all of maxproc=4036.

Multi-uid staged attack (proc Count ≈ global nprocs; ps ax frozen at 146):

baseline → 25   maxx→732   u1002→1.41K   u1003→2.10K   u1004→2.79K
u1005→3.48K   u1006→3.68K (+203; system nprocs check now pre-blocks fdcopy)

Then, with nprocs permanently ~3680/4036, a root fork-bomb:

$ /root/forktest_bomb
forktest_bomb: root fork() EAGAIN after 272 children (errno=35 Resource temporarily unavailable)
forktest_bomb: ROOT RESULT ok=272 eagain=3  (clean system would allow ~4036)

Root can fork only ~272 children (vs ~3890 on a clean system) — a ~93 % collapse — and is itself fork-blocked. dmesg corroborates with maxproc limit exceeded by uid 0. The leaked slots are permanent (they do not recover after the attackers exit); only a reboot clears them.

Caveats / precision

• The original PoC (fork_leak.c) is not a valid trigger (mmap ≠ M_FILEDESC). It is retained for provenance; exhaust.c is the working trigger.
• Full maxproc exhaustion needs ~4–6 unprivileged uids (single user is capped at ~1009 leaked slots by its own leaked per-uid chgproccnt). On any multi-user system (or for any user able to raise RLIMIT_NPROC / run from several accounts) full system-wide fork-DoS is straightforward. Even a single user permanently destroys ~18–25 % of system fork capacity and permanently fork-blocks their own uid.
• No kernel panic occurred at any point; the failure is a clean ENOMEM leak, exactly the path cited.

Files in this folder

Fix

fix.diff adds a full teardown of the partially-built p2 on the fdcopy-failure path (reversing every acquisition from :491 back through :415/:421), plus a new symmetric proc_remove_allproc() helper in kern_proc.c (the inverse of proc_add_allproc()). This supersedes the finding markdown's primary proposal (drop M_NULLOK from fdcopy): dropping M_NULLOK would convert the leak into a panic("malloc limit exceeded") at kern_slaballoc.c:877 (worse for availability). The teardown keeps fdcopy's clean ENOMEM failure mode and makes fork1 correctly clean up after it — fixing the root cause and adding defense-in-depth for any future error path after p2 allocation.

Fix VALIDATION (Phase 8 — built + booted a single-fix kernel)

Verified on a patched kernel built and booted in the guest.

Before/after contrast (the SAME ./exhaust trigger)

The decisive point: on #1 the SAME trigger that leaked +1416 struct proc on #0 now leaves proc Count exactly at baseline (24) — every acquisition the teardown reverses (p2 kmalloc, uidpcpu, crhold, sigacts ref, textvp vref, textnch cache_copy, reaper hold, proc_add_allproc, nprocs++, chgproccnt++) is released. The "Allocs" column climbs across runs (8.68K after 3 runs) but the live count stays flat at 24 — the leaked objects are now freed, not orphaned.

Determinism: 3 consecutive ./exhaust runs on #1, each triggering thousands of fdcopy failures; after every run proc/subproc/lwp/file_desc return to baseline. Root fork capacity on #1: forktest 2000 fork+wait → ok=2000 eagain=0 enomem=0, no maxproc limit in dmesg — system-wide fork capacity fully intact.

Fix verdict: fixed. Bad behavior present on #0, gone on the single-fix #1 kernel. fix.diff closes the root cause.

(fix-validation evidence: fix_build.log = full nativekernel output, fix_run.log = before/after contrast + determinism + root capacity.)