DragonFlyBSD Kernel Audit
DF-0031 / run.log
← back to finding ↓ download raw
=== 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) ===