DF-2553 VERDICT -- sbuf_uionew int truncation + full-resid uiomove

STATUS : reproduced (primitive proven on live kernel; LATENT KPI -- zero in-tree callers today, so no user-reachable path on a stock kernel) IMPACT : none today (see honest assessment below); primitive strength = arbitrary-length attacker-content kernel heap overflow if any future caller feeds a user uio into sbuf_uionew CONF. : certain

ROOT CAUSE (verified line-by-line on the running kernel)

sys/kern/subr_sbuf.c:246

s = sbuf_new(s, NULL, uio->uio_resid + 1, 0);

sbuf_new() (subr_sbuf.c:210) takes int length; uio->uio_resid is ssize_t. uio_resid = 0x100000000 -> the (resid + 1) argument is 0x100000001, truncated to int = 1 -> sbuf_newbuf() (subr_sbuf.c:183) sets s_size = 1 and SBMALLOC(1) (subr_sbuf.c:197) = kmalloc(1, M_SBUF) -> 8-byte chunk of the per-CPU slab zone class 0 (kern_slaballoc.c zoneindex: sizes 0-127 -> 8-byte chunks).

subr_sbuf.c:251

*error = uiomove(s->s_buf, uio->uio_resid, uio);

uiomove() (kern/kern_subr.c:96) takes size_t n -- NO truncation: n = 0x100000000. For UIO_WRITE + UIO_USERSPACE it runs copyin(iov->iov_base, cp, min(iov_len, n)) per iov (kern_subr.c:117-156), so a fully-committed first iov of any size <= n is copied in its entirety into the 1-byte allocation before any fault on a later iov.

Additional latent edge: resid in [0x7fffffff, 0x100000000) makes (int)(resid+1) <= 0 -> KASSERT(length >= 0) at subr_sbuf.c:213 PANICS an INVARIANTS kernel (this guest config has INVARIANTS).

WHAT THE RIG PROVED (baseline kernel, verbatim subr_sbuf.c sha256 854fe3f4bf6e5b10d09e503c24304dbc432ffad83a3d67c7c8f54699741ac44e)

1. TRUNCATION AT ALLOCATION - mode 2: kmalloc(0x100000001) = NULL (a faithful 4GiB+1 allocation is impossible on the 4 GB guest) while the truncated (int)1 kmalloc succeeds with usable size 8 (run.mode2.log). - mode 1: sbuf_uionew did NOT return ENOMEM (which a faithful kmalloc(0x100000001) would have produced) -- it proceeded to uiomove and returned EFAULT, i.e. sbuf_new SUCCEEDED: the allocation could only have been the truncated 1-byte one. - mode 0: success path prints s_size = (int)(resid+1) = 257 for resid = 256, directly observing the length relation.

2. COUNT MISMATCH + OVERFLOW WITH ATTACKER BYTES (run.mode1.log, run.stress3.log: 3/3 consecutive runs, each 63/63 canaries) - uio after the call: resid 0x100000000 -> 0xfffffe00, iov0.len 512 -> 0: uiomove consumed EXACTLY the 512 committed attacker bytes, then faulted on the PROT_NONE iov1 -> *error = EFAULT. - 8192 one-byte canaries sprayed in the same slab zone; the sbuf chunk placement was made deterministic (LIFO-verified hole); after the call 63 adjacent canaries (the 512 bytes behind the 1-byte chunk) were corrupted, and EVERY one of the 63 matched the user pattern "DF2553PWN" at its exact address-derived cyclic offset (full-8-byte-pattern-match=63). That is a byte-exact, ordered, linear copy of userspace memory into kernel heap past a 1-byte allocation. - The guest kept running cleanly after every run: the corruption is surgical and deterministic (it landed only on canaries), which is exactly the property an exploit wants -- not a random crash. - Overflow length is attacker-chosen (iov0 size up to the committed user mapping; the count param allows up to 0x100000000) and content is attacker-chosen. On this non-SMAP/non-KASLR snapshot guest, corruption of the shared 8-byte slab zone (including freelist-eligible chunks) is the classic route toward uid=0.

3. CONTROL - mode 0: resid 256 -> success, s_size 257, s_len 256, data == user bytes, zero canary corruption; identical before and after the overflow runs (allocator healthy).

HONEST ASSESSMENT (why impact is "none" today)

rg over the whole sys/ tree: sbuf_uionew has ZERO callers -- only the prototype (sys/sys/sbuf.h:94) and the definition (sys/kern/subr_sbuf.c:238). It is an exported KPI ("string buffers" API) awaiting users, and the harness had to fabricate the uio because no stock kernel path supplies one. Therefore NO local or remote attacker can reach this on a stock DragonFly kernel today -- not even root (no plumbing exists). Severity is latent: Medium as filed.

Why it still matters: - The same code is exported KPI; any future caller that passes a uio built from user input (the exact pattern sbuf_uionew was designed for) instantly turns this into an arbitrary-length heap overflow -- the rig shows content, length, and placement are all attacker controlled and the failure is masked as EFAULT. - FreeBSD carries the identical latent bug (subr_sbuf.c rev 255805 ancestry); the fix applies there too. - The [0x7fffffff, 0x100000000) band panics INVARIANTS kernels via the negative-length KASSERT if a caller appears.

FIX VALIDATION (A/B on the same guest)

fix.diff (in-pack, git apply -p1) rejects resid < 0 or > 0x7ffffffe with EINVAL before any allocation.

baseline kernel : mode 1 -> EFAULT after 512-byte smash, 63/63 canaries corrupted; mode 0 -> s_size 257 data OK patched kernel : mode 1 -> EINVAL, uio UNTOUCHED (0 bytes copied, resid still 0x100000000), corrupted=0; mode 0 -> byte-identical success output (s_size=257 s_len=256 data=44 46 32 35 35 33 50 57)

See fix_run.log (patched rerun) vs run.stress3.log (baseline) and fix_build.log (full untrimmed fixed-kernel build).

RIG FIDELITY NOTES

• Runtime kldload GPFs on this guest, so the harness is compiled into the stock config X86_64_GENERIC (only additions: kern/kern_df2553.c
• one conf/files line; subr_sbuf.c untouched, sha-gated).
• The trigger sysctl is root-only and the trigger program is run as root: the finding is about the KPI landmine, not a stock attack path.
• The trigger is pinned to CPU 0 (usched_set) because the slab allocator is per-CPU; canary grooming exploits LIFO freelists (kern_slaballoc.c _kfree: chunk pushed on z_LChunks head).
• run.2.mode1.log keeps one intermediate run where the hole landed on the zone fill frontier (no canaries behind): 512 bytes were still copied (uio mutation proves it) but no canary was hit. Harness v3 selects the lowest-address canary of the frontier zone; all runs since reproduce 63/63.
• My baseline nativekernel build log was wiped by the mandatory vm.sh reset with-src before the fix build; fix_build.log contains the full untrimmed compile of the same harness (plus the 12-line fix), and build.snapshot-stock-kernel.log is the stock kernel build log present on the snapshot.

CONCLUSION

The bug is real and its primitive is as strong as claimed (arbitrary length, arbitrary content, deterministic placement, error-masked). It is latent: zero callers today. The one-line-range guard in fix.diff kills it with no behavior change for legitimate sizes (validated A/B). Recommended upstream: apply the guard, and consider changing the KPI to take ssize_t*/return the needed length so future callers cannot silently truncate.

Fix status (batch validation)

Applied with the 36 sibling fix.diffs of this batch in findings/poc/_batch41/all_fixes.patch; single in-guest make -j6 nativekernel KERNCONF=X86_64_GENERIC completed RC=0 with zero errors under -Werror (full log: findings/poc/_batch41/fix_build8.log). Behavior A/B intentionally skipped for this Info-tier item.