DF-0924 — PoC: kernel memory exhaustion via large read() resid

Goal

Demonstrate that an unprivileged local user can force the kernel to kmalloc up to ~2 GiB per read() call against /proc/<pid>/map, by passing a huge resid.

Build & run

cc -o alloc_dos alloc_dos.c
./alloc_dos        # in several terminals in parallel
vmstat -w 1        # observe freemem collapse

Expected output

vmstat shows free memory collapsing toward zero; the system becomes unresponsive; OOM-killer activity may appear; or procfs_map.c:78 EIO storms appear in dmesg when the kernel finally fails the allocation.

On a 2 GiB-RAM VM, expect the panic / hang within seconds.

Notes

• The kernel kmalloc is up-front (sbuf_new with flag 0; see subr_sbuf.c:178-205).
• The fix is to cap buflen at a sane bound (e.g. 1 MiB) regardless of the caller's requested read length; uiomove_frombuf already handles positional truncation, so capping only changes how many syscalls the reader issues, not the visible output.

DF-0924 — Attacker-controlled kernel heap allocation size via read() resid in /proc/<pid>/map

Verdict

REPRODUCED + FIX VALIDATED. The bug is real and the authored fix.diff closes it on a built-and-booted single-fix kernel.

Summary

procfs_domap() sizes its scratch sbuf from uio->uio_offset + uio->uio_resid (sys/vfs/procfs/procfs_map.c:61). The only upper bound is buflen >= INT_MAX (:75), so the caller's read() length directly controls the size of the up-front kernel allocation: sbuf_new(sb, NULL, buflen+1, 0) at :77 with flag 0 (no SBUF_AUTOEXTEND) makes sbuf_newbuf() at sys/kern/subr_sbuf.c:197 do an unconditional kmalloc(buflen+1, M_SBUF, M_WAITOK|M_ZERO) of up to ~2 GiB up front, regardless of how little data the pseudo-file actually produces. uio_resid is set by the length of read(), so the unprivileged reader alone decides how many bytes the kernel allocates.

This is CWE-789 (Uncontrolled Memory Allocation) — a local denial-of-service vector. It is not a write/corruption primitive: writes into the sbuf are bounded by the actual formatted map output, and uiomove_frombuf at :245 truncates the copyout to sbuf_len(sb). So there is no escalation path.

Mechanism (trigger -> primitive -> effect)

1. Trigger — unprivileged maxx (uid 1001) opens /proc/self/map and calls pread(fd, buf, 0x7ffffff0, 0). uio_resid = 0x7ffffff0.
2. Primitive — in procfs_domap: - buflen = uio->uio_offset + uio->uio_resid = 0x7ffffff0 (procfs_map.c:61) - guard buflen >= INT_MAX does not fire (0x7ffffff0 < 0x7fffffff) (:75) - sbuf_new(sb, NULL, buflen+1, 0) (:77) -> sbuf_newbuf (subr_sbuf.c:178) -> s->s_buf = SBMALLOC(s->s_size) = kmalloc(0x7ffffff1, M_SBUF, M_WAITOK|M_ZERO) (subr_sbuf.c:197, subr_sbuf.c:53) - the kernel synchronously allocates and zero-fills ~2 GiB before formatting a few KB of map entries.
3. Effect (DoS) — two observable consequences: - CPU/memory waste per call: the up-front kmalloc+zero of ~2 GiB takes ~2.5 s on this VM, vs ~60 µs for a normal-sized read returning the same few KB. (alloc_dos --time) - Kernel panic via per-type limit exhaustion: when several processes drive concurrent ~2 GiB M_SBUF allocations, the type's ks_limit is exceeded and kern_kmalloc.c:706 fires panic("sbuf: malloc limit exceeded") from within procfs_domap -> sbuf_new -> kmalloc. (alloc_dos --starve 4 8)

Evidence (before / after)

Baseline — unpatched 6.5-DEVELOPMENT #0 (Thu Jul 2 06:02:54 UTC 2026)

Timing (alloc_dos --time) — same ~1.5 KB of map output, ~44,000× slower:

[time] resid=4096        pread=1421    kernel-side elapsed=0.000057 s
[time] resid=0x7ffffff0 pread=1615    kernel-side elapsed=2.752359 s

Repeated runs: 2.66 s, 2.53 s, 2.59 s, 2.75 s — deterministic.

Panic (alloc_dos --starve 4 8 as uid 1001) — dfbsd-qemu/boot.log:

panic: sbuf: malloc limit exceeded
cpuid = 0
Trace beginning at frame 0xfffff801183fb598
_kmalloc() at _kmalloc+0xb09 0xffffffff806578c9
_kmalloc() at _kmalloc+0xb09 0xffffffff806578c9
sbuf_new() at sbuf_new+0x66 0xffffffff806a0dc6
procfs_domap() at procfs_domap+0x75 0xffffffff807114a5
procfs_rw() at procfs_rw+0x235 0xffffffff80713065
vop_read() at vop_read+0x57 0xffffffff8070a487
Debugger("panic")
Stopped at      Debugger+0x7c:  movb    $0,0xbdaf09(%rip)
db>

The stack names the exact buggy function and sink cited in the finding. Guest dies; vm.sh status ⇒ down.

Patched — single-fix kernel 6.5-DEVELOPMENT #1 (Tue Jul 14 13:23:50 UTC 2026)

fix.diff applied to /usr/src, make -j6 nativekernel KERNCONF=X86_64_GENERIC, installed stripped kernel + debug to /boot/kernel/, rebooted.

kern.version: DragonFly 6.5-DEVELOPMENT #1: Tue Jul 14 13:23:50 UTC 2026 sha256(/boot/kernel/kernel) = 483c43b88368f134ab29389441d674e88267129eaa5485547494ef4242c474f2

Timing — ~1-5 ms (cap = 1 MiB):

[time] resid=4096        pread=1421    kernel-side elapsed=0.000062 s
[time] resid=0x7ffffff0 pread=1615    kernel-side elapsed=0.001451 s   (run 1)
[time] resid=0x7ffffff0 pread=1615    kernel-side elapsed=0.004864 s   (run 2)
[time] resid=0x7ffffff0 pread=1615    kernel-side elapsed=0.003246 s   (run 3)

~1.5 ms vs 2.75 s baseline = ~1,900× faster.

Starve (--starve 4 8) — no panic, freemem barely moves:

[starve] peak transient kernel alloc target ≈ 4 × 2047 MiB = 8191 MiB
  t=0.0s  free_pages=849808  (3319 MiB)
  ... (8 s of samples, all in 3315-3318 MiB range) ...
  t=8.0s  free_pages=848919  (3316 MiB)
[starve] free_pages start=849808  min_observed=848662  end=849739

Min free = 3315 MiB (only ~4 MiB delta = 4 × 1 MiB cap, transiently in-flight). Guest stays UP. Compare baseline: same input → kernel panic.

Impact

Local denial of service (kernel memory exhaustion → panic) by an unprivileged user, default config (procfs is mounted by default), no special privileges. No escalation, no corruption — the sbuf write surface is bounded by actual map output and uiomove_frombuf truncates the copyout. Severity Low is correct (CVSS A:L). The finding's prose said "OOM / EIO storms / unresponsive"; in practice on this 4 GiB VM the dominant observed effect is the hard kernel panic from per-type kmalloc limit exhaustion, which is more severe than the finding's "freemem collapse" wording suggests but still within the DoS class.

Why no escalation (Phase 6 analysis)

The primitive is read-only in the corruption sense: the attacker controls the size of a transient M_WAITOK|M_ZERO allocation but not its contents (the buffer is zeroed, then filled only with sbuf_printf map output). There is no write to a victim object, no UAF, no type confusion, no function-pointer or refcount corruption. The "primitive" is purely resource consumption. There is therefore no chain to develop — the realistic impact ceiling is DoS, which is demonstrated.

PoC changes

The original alloc_dos.c allocated a 2 GiB userland buffer with malloc + memset, which conflates userland memory pressure with the kernel allocation under test and made the demonstration noisy on small VMs. Rewritten to: - --time mode: time pread() with small vs huge resid on the same fd. The userland buffer is a fixed 8 KB (only the first min(sbuf_len, resid) bytes are ever copied out). The 2.5 s vs 60 µs contrast cleanly isolates the kernel-side up-front kmalloc+zero as the only variable. - --starve N S mode: fork N children each looping the huge-resid pread(), parent samples vm.stats.vm.v_free_count every 0.25 s for S seconds. On the unpatched kernel this drives the per-type M_SBUF limit over the edge and panics; on the patched kernel freemem barely moves.

Recommended fix

fix.diff in this folder — cap buflen at 1 MiB (PROCFS_MAP_MAXBUF) before the sbuf_new call. The output is positionally truncated by uiomove_frombuf at :245, so a smaller buffer only changes how many syscalls a reader issues to consume the same total output — the visible content is unchanged. Supersedes the finding markdown's ## Recommended fix proposal (which was identical in spirit but sketched as a single-line clamp without the explanatory comment or #define placement used here).