DF-0031 / run.log
=== DF-0031 PoC run on unpatched #0 kernel (6.5-DEVELOPMENT #0, Thu Jul 2 06:02:54 UTC 2026) ===
Run as maxx (uid 1001), timeout 25s.
Command: cd poc/DF-0031 && ./pipe_leak
Output:
[*] holding 32526 pipe fds to build kernel_map pressure
[*] opened=0 failures(likely underflow-leak path)=1000000
[*] check `vmstat -z` / pipe zone and kernel_map free space for cumulative KVA/struct leak
RUN_EXIT=0
=== Diagnosis: PoC does NOT reach the bug path ===
- PoC holds 32526 fds (= process fd limit 32528 minus stdin/stdout/stderr), i.e. 16263 pipes.
(README assumed HOLD=200000; impossible: kern.maxfilesperproc=32528, kern.maxfiles=130112.)
- All 1,000,000 subsequent pipe() calls fail with EMFILE (errno 24, "Too many open files").
EMFILE is returned by falloc() at sys/kern/sys_pipe.c:292-297, NOT by pipe_create()'s
second pipespace() at sys/kern/sys_pipe.c:437. The failure path the bug lives on is never reached.
- Direct confirmation (separate C test exhausting fds):
pipe rc=-1 errno=24 (Too many open files) after 16263 pipes
=== kernel_map not dented ===
vm.kvm_size = 8795004596224 (~8.0 TB)
vm.kvm_free before = 8790279712768
vm.kvm_free after = 8790279712768 (IDENTICAL — zero leak)
Max system-wide pipes = kern.maxfiles/2 = 65056 -> ~4 GB KVA (0.00005% of kvm).
To exhaust kernel_map and trigger the 2nd-pipespace ENOMEM would need ~145 million pipes:
impossible for an unprivileged user given fd limits.
=== Guest status after run: up (no panic, no crash) ===