sbuf_drain() does not validate the drain callback's return value — a drain returning 0 yields a silent, unbounded, content-controlled linear kernel-heap overflow on production kernels

Summary

sbuf_drain() takes the drain callback's return value on faith: the only guard against a callback returning 0 ("consumed nothing, no error") or a value greater than s_len is a KASSERT, compiled out of production kernels. With a drain returning 0, sbuf_put_byte() falls through to s->s_buf[s->s_len++] = c; while SBUF_FREESPACE(s) ≤ 0 — it writes past the end of the heap allocation, once per byte, for as long as the caller keeps appending, and neither s_error nor the return of sbuf_cat()/sbuf_printf() ever signals a problem. With a drain returning len > s_len, s->s_len -= len goes negative and the following memmove uses a huge size_t.

Threat model & preconditions

No in-tree drain misbehaves (sbuf_sysctl_drain returns len or -error) and installing one requires root (KLD/custom kernel) — no unprivileged uid0 route today. This is a hardening gap whose failure mode is full kernel heap corruption for any future or third-party drain regression: content-controlled linear overflow.

Proof of contest

VERIFIED on a purpose-built no-INVARIANTS DragonFly kernel (compiled-in trigger via debug.df2845 sysctl): sbuf_cat rc=0 s_error=0 s_len=255 s_size=32 + "OVERFLOW CONFIRMED: 224 byte(s) written past the end of the 32-byte heap allocation". On the INVARIANTS kernel the same trigger panics Bad drain amount 0 for sbuf (panic.txt). fix.diff (runtime check: len==0 || len>s_len → s_error=EDOOFUS) validated in-guest: patched no-INVARIANTS kernel stays in-bounds (s_len=31) and propagates rc=−1/EDOOFUS.

Recommended fix

See findings/poc/DF-2845/fix.diff (validated).

Timeline

• 2026-09-02 Discovered during pass-2 audit of subr_sbuf.c (GLM 5.3); no-INVARIANTS overflow reproduced + fix validated same run.