DF-0031 — PoC

pipe_leak.c — pipe->open_count underflow on pipe_create partial failure leaks kernel KVA + pipe struct (memory-pressure amplification DoS).

The bug

pipe_create (sys/kern/sys_pipe.c): *pipep = pipe (:433) is set before the pipespace() calls (:434/:437), and open_count = 2 (:445) only after both succeed. If pipespace(&bufferB) fails (vm_map_find ENOMEM on kernel_map), pipe_create returns with open_count still 0. kern_pipe's error path (:287-288) then calls pipeclose() twice; each pipeclose (:1272) does atomic_fetchadd_int(&open_count, -1) == 1 to gate the free. With open_count = 0 the sequence underflows 0 → 0xFFFFFFFF → 0xFFFFFFFE, never == 1, so the pipe struct + bufferA's KVA are leaked permanently and open_count is corrupted.

Reachability

Unprivileged. Each open pipe holds ~2*pipe_size of kernel_map KVA; holding many pushes kernel_map toward exhaustion, after which new pipe_create calls hit the second-pipespace failure and leak further — self-amplifying. Pure availability (KVA/struct leak); no confidentiality/integrity impact.

Build & run (unprivileged, disposable VM)

cc -o pipe_leak findings/poc/DF-0031/pipe_leak.c
./pipe_leak

Expected output (bug present)

Cumulative kernel_map free-space shrinkage and pipe-zone struct growth (observed via vmstat -z / vmstat -m) that never reclaims, worsening the OOM. No standalone panic.

DF-0031 — VERDICT

Verdict: NOT REPRODUCED (latent code bug confirmed; PoC cannot trigger it)

The code bug is real but not reachable by an unprivileged user on the default-config guest. The PoC does not reproduce the claimed leak because its precondition (kernel_map exhaustion) is impossible given default fd limits.

The code bug (confirmed by source trace)

pipe_create (sys/kern/sys_pipe.c:414-448) sets *pipep = pipe (:433) and calls pipespace() for bufferA (:434) and bufferB (:437) before setting pipe->open_count = 2 (:445). The pipe is allocated with M_ZERO (:426), so on a partial failure (bufferA succeeds, bufferB's vm_map_find returns ENOMEM), pipe_create returns non-zero with open_count still 0.

kern_pipe's error path (sys/kern/sys_pipe.c:286-290) then calls pipeclose() twice. pipeclose (sys/kern/sys_pipe.c:1272) gates the free on atomic_fetchadd_int(&pipe->open_count, -1) == 1. With open_count = 0:

→ the pipe struct + bufferA's KVA leak permanently; open_count is corrupted (underflow). This is a genuine correctness bug on the failure path.

Why it is NOT reproducible here (reachability)

The failure path requires pipespace(&bufferB) to fail, i.e. vm_map_find on kernel_map to return ENOMEM. That needs kernel_map exhaustion. On this guest:

To exhaust kernel_map and trip the 2nd pipespace ENOMEM would need ~145 million pipes — impossible given fd limits. Direct measurement: exhausting the process fd table, pipe() fails with EMFILE (errno 24, "Too many open files") after 16,263 pipes. That is falloc() failing at sys/kern/sys_pipe.c:292-297, not pipe_create()'s pipespace(). The bug path is never entered.

The PoC's own HOLD = 200000 is itself impossible (> maxfiles).

Run evidence (unpatched #0 kernel)

[*] holding 32526 pipe fds to build kernel_map pressure   <- hit fd limit, not kvm
[*] opened=0  failures(likely underflow-leak path)=1000000 <- all EMFILE, not the bug
vm.kvm_free before = 8790279712768
vm.kvm_free after  = 8790279712768   <- IDENTICAL (zero leak)

So: not_reproduced, category (d) genuinely not reachable on this kernel via the unprivileged PoC path — but not a false positive (the code bug is real and would manifest if kernel_map were ever exhausted, e.g. by root loading huge modules, or on a system with a much smaller KVA window).

Impact ceiling

Pure availability, and only latent: a self-amplifying KVA/struct leak if the precondition can be met. On a default-config DragonFlyBSD guest the precondition is unreachable for an unprivileged user, so the realistic impact is none. This matches the finding's Low severity (CVSS A:L).

No escalation (resource leak class, non-corruption)

Even if the leak fired, it is a resource leak (KVA + struct), not a memory- corruption primitive — there is no write/UAF/double-free, so there is no path to uid=0. The ceiling is DoS via KVA exhaustion, which is itself unreachable here.

Fix (authored in fix.diff, validated)

Move pipe->open_count = 2; from after the two pipespace() calls to before them (right after *pipep = pipe;). Then on a partial failure, kern_pipe's double-pipeclose cleanup decrements 2 → 1 → 0; the second call sees old==1 and frees/caches the pipe (and pipe_free_kmem releases bufferA's KVA). No underflow, no leak.

The cached-pipe path is unaffected: a cached pipe already has open_count = 0 (decremented to 0 when cached in pipeclose), and the early open_count = 2 overwrites it correctly on success.

Fix validation (Phase 8)

fix_status = not_testable: the leak precondition is unreachable on default config, so there is no observable bad behavior on either kernel to contrast. The fix is validated by apply + compile + boot + no-regression + source inspection of the closed error path.

PoC changes

None to pipe_leak.c (it builds and runs as-is; it simply cannot reach the bug path). Added: build.sh, run.sh, fix.diff, VERDICT.md, manifest.json, full logs (run.log, fix_build.log, fix_run.log, env.txt).

kernel_refs (confirmed)

• sys/kern/sys_pipe.c:433 — *pipep = pipe handed out before pipespace.
• sys/kern/sys_pipe.c:434,437 — the two pipespace() calls.
• sys/kern/sys_pipe.c:445 — open_count = 2 set only after both succeed (the bug).
• sys/kern/sys_pipe.c:286-290 — kern_pipe double-pipeclose error cleanup.
• sys/kern/sys_pipe.c:1272 — pipeclose fetchadd == 1 free gate (underflow site).