DF-2552 — sbuf_extend / sbuf_extendsize int-truncation heap overflow

Summary

sbuf_extend() in sys/kern/subr_sbuf.c computes the new buffer size via sbuf_extendsize(s->s_size + addlen). The sum (ssize_t + int) is narrowed to int (the parameter type of sbuf_extendsize). When the sum exceeds INT_MAX, the narrowed argument is negative, sbuf_extendsize returns 16, and sbuf_extend's memcpy overflows the 16-byte allocation by s_size - 16 bytes.

Status: The code defect is real and confirmed at the harness level. The bug is latent — sbuf_bcopyin/sbuf_copyin/sbuf_uionew (the only functions that pass large addlen to sbuf_extend) have zero in-tree callers, so it is not reachable from unprivileged userspace on the current kernel. A fix.diff is provided as defense-in-depth and validated on a single-fix kernel.

Files

• arith_proof.c — userspace arithmetic proof (replicates exact sbuf arithmetic)
• trigger.c — userspace trigger for the kernel-module harness
• sbuftest_mod/sbuftest.c — kernel module that creates /dev/sbuftest and calls sbuf_bcopyin with crafted length
• sbuftest_mod/Makefile — kld module Makefile
• build.sh — builds arith_proof and trigger
• run.sh — runs arith_proof (non-destructive)
• fix.diff — git-apply-able fix (overflow guard in sbuf_extend)
• VERDICT.md — full analysis
• manifest.json — artifact catalog

Build

./build.sh    # builds arith_proof and trigger (userspace, as unprivileged user)

Run

./run.sh      # runs the arithmetic proof (non-destructive)

Expected output (arithmetic proof)

The proof shows: - Normal case (sbuf_put_byte path, addlen=1): correct, no overflow. - Bug case (sbuf_bcopyin path, crafted len): sbuf_extendsize returns 16 for a 4096-byte buffer → 4080-byte overflow. - Fixed version: detects overflow, returns ENOMEM.

Kernel-module harness (requires root to load)

# On the guest (as root):
cd /root/sbuftest_mod && make obj && make
cp /usr/obj/root/sbuftest_mod/sbuftest.ko /root/sbuftest.ko
kldload /root/sbuftest.ko

# As unprivileged user:
cd ~/poc/DF-2552 && ./trigger

# Check result (as root):
dmesg | grep SBUFTEST
# Unpatched: "post-overflow s_size=16" (overflow occurred)
# Patched:   "post-overflow s_size=4096" (extend refused, no overflow)

DF-2552 — sbuf_extend / sbuf_extendsize int-truncation heap overflow

Verdict: REPRODUCED (primitive confirmed at code + harness level); LATENT — not reachable from unprivileged userspace on the current kernel.

Severity: Medium (latent code defect; defense-in-depth fix applied)

The bug (confirmed)

sys/kern/subr_sbuf.c:158 — sbuf_extend() computes the new buffer size as:

newsize = sbuf_extendsize(s->s_size + addlen);

• s->s_size is ssize_t (64-bit on x86_64).
• addlen is int (32-bit).
• The sum s->s_size + addlen is computed as ssize_t (no 64-bit overflow for realistic values).
• But sbuf_extendsize() takes int size (subr_sbuf.c:132), so the ssize_t sum is narrowed to int when passed.

If s->s_size + addlen > INT_MAX (0x7FFFFFFF), the narrowing produces a negative int. sbuf_extendsize() then: 1. Takes the size < SBUF_MAXEXTENDSIZE (4096) branch (true for any negative int). 2. Returns SBUF_MINEXTENDSIZE = 16. 3. The KASSERT(newsize >= size) at line 143 passes (16 >= negative).

Back in sbuf_extend():

newbuf = SBMALLOC(newsize);         // kmalloc(16, M_SBUF, M_WAITOK|M_ZERO)
memcpy(newbuf, s->s_buf, s->s_size); // memcpy(16-byte-buf, old-buf, s_size=4096) → 4080-byte overflow!

The memcpy writes s->s_size bytes (e.g. 4096) into the 16-byte allocation, producing a heap overflow of s->s_size - 16 bytes.

Arithmetic proof (run on guest as unprivileged user)

arith_proof.c replicates the exact sbuf_extendsize/sbuf_extend arithmetic. Key result for the trigger scenario:

s_size=4096, addlen=2147483647 (INT_MAX)
s_size + addlen = 2147487743  (as ssize_t)
(int)(sum)      = -2147479553  (narrowed — what sbuf_extendsize receives)
BUGGY newsize   = 16
*** HEAP OVERFLOW: kmalloc(16) then memcpy(4096 bytes) => 4080-byte overflow! ***

Kernel-module harness (proves the actual primitive in the running kernel)

Since sbuf_extend/sbuf_extendsize are static, the only way to drive a large addlen into sbuf_extend from the exported API is through sbuf_bcopyin() (or sbuf_copyin()), which computes addlen = (int)(len - SBUF_FREESPACE(s)).

The harness module (sbuftest_mod/) creates /dev/sbuftest (mode 0666). Its ioctl handler: 1. Creates an sbuf via sbuf_new(NULL, NULL, 4096, SBUF_AUTOEXTEND) → s_size=4096. 2. Calls sbuf_bcopyin(sb, &dummy, 2147487742) → addlen = (int)(2147487742 - 4095) = INT_MAX. 3. Inside sbuf_extend: s_size + addlen = 4096 + INT_MAX > INT_MAX → narrowed to negative → sbuf_extendsize returns 16 → kmalloc(16) → memcpy(4096) → 4080-byte heap overflow.

Loading the module requires root (kldload). This is a HARNESS that proves the primitive exists in the actual kernel code — NOT a valid unprivileged→root escalation chain (see bright-line rule). The trigger (ioctl) is unprivileged, but the module setup is root-only.

Baseline (#0 unpatched kernel) — module output (dmesg):

SBUFTEST: sbuf created, s_size=4096, s_len=0, freespace=4095
SBUFTEST: trigger_len=2147487742, addlen will be (int)2147483647 = 2147483647
SBUFTEST: calling sbuf_bcopyin -> about to overflow kernel heap!
SBUFTEST: SURVIVED (unexpected — heap is corrupted, expect panic soon)
SBUFTEST: post-overflow s_size=16 (should be 16)

post-overflow s_size=16 is the smoking gun: sbuf_extend allocated 16 bytes and copied 4096 bytes into it. The kernel survived because the old buffer was zeroed (M_ZERO), so the overflow wrote zeros into adjacent slab chunks — a silent heap corruption, even more dangerous than a panic.

Reachability analysis (why this is LATENT)

sbuf_bcopyin(), sbuf_copyin(), and sbuf_uionew() are the only functions that pass a user-influenced addlen to sbuf_extend(). Verified via rg -n 'sbuf_bcopyin|sbuf_copyin|sbuf_uionew' sys/ (excluding subr_sbuf.c and sbuf.h):

ZERO in-tree callers. These functions are exported (T in nm /boot/kernel/kernel) but never called by any kernel code.

All live sbuf growth in the kernel happens one byte at a time: - sbuf_put_byte() → sbuf_extend(s, 1) — addlen is always the constant 1. - sbuf_bcat(), sbuf_cat(), sbuf_printf() all route through sbuf_put_byte().

For the sbuf_extend(s, 1) path to trigger the bug, s_size would need to already be at or above INT_MAX - 1 (~2 GiB). Reaching that via byte-at-a-time growth requires writing ~2 GiB of data into an sbuf and ~28 doublings of the allocation — an enormous kernel heap allocation that would fail (OOM) long before approaching INT_MAX. No kernel path does this.

Conclusion: The int-truncation defect is real at the code level and confirmed by the harness, but it is not reachable from unprivileged userspace on the current kernel. It is a latent code defect — a future caller that wires sbuf_bcopyin/sbuf_copyin into a syscall/ioctl path would instantly turn it into an exploitable heap overflow.

Fix

fix.diff adds an overflow guard in sbuf_extend() before the sbuf_extendsize() call:

if (addlen < 0 || s->s_size > (ssize_t)0x7fffffff - addlen)
    return (-1);

This rejects any extend request where s->s_size + addlen would exceed INT_MAX, preventing the narrowing-to-negative and the resulting undersized allocation. The caller (sbuf_bcopyin/sbuf_copyin) already handles a failed extend gracefully (clamps the write to SBUF_FREESPACE); sbuf_put_byte sets s->s_error = ENOMEM.

Fix validation (single-fix kernel)

Built X86_64_GENERIC with only this diff applied (#1, Sat Aug 8 21:04:27 UTC 2026).

The fix is validated: on the patched kernel, sbuf_extend correctly detects the overflow and returns -1, leaving s_size at 4096. No heap overflow occurs.

How to reproduce

# Build the arithmetic proof + trigger
cd findings/poc/DF-2552
./build.sh          # builds arith_proof and trigger

# Run the arithmetic proof (non-destructive, runs as unprivileged user)
./run.sh            # shows the int-truncation arithmetic

# Kernel-module harness (requires root to load):
# On the guest:
cd /root/sbuftest_mod && make obj && make
cp /usr/obj/root/sbuftest_mod/sbuftest.ko /root/sbuftest.ko
kldload /root/sbuftest.ko
# As unprivileged user:
./trigger           # triggers sbuf_bcopyin with crafted length
# Check dmesg for "post-overflow s_size=16" (unpatched) or "s_size=4096" (patched)