xio_init_kbuf: size_t→int truncation of kbytes at kern_xio.c:121 corrupts xio_bytes negative while returning success

Summary

In xio_init_kbuf's load loop, kbytes (size_t) is assigned into n (int) at :121. For a caller requesting kbytes ≥ 2^31+4097 with a page-aligned kbase, the first iteration consumes one page leaving kbytes > INT_MAX; (int)kbytes wraps negative, so the second iteration executes kbytes -= n (wraps up to exactly 2^32) and xio_bytes += n (signed overflow → ≈ −2147475455), after which n==0 exits the loop. The error guard at :131 does not fire because n==0 — the function returns 0 (success) holding only 2 pages while xio_bytes is negative garbage. Distinct mechanism from DF-0160 (different line, different threshold, corrupts xio_bytes rather than truncating). Proven by exact two's-complement arithmetic simulation. Latent: xio_init_kbuf has ZERO in-tree callers (only the prototype in xio.h); reachable only by a third-party KLD passing a >2GiB kernel buffer. Fail-safe direction downstream (negative xio_bytes makes copy guards EFAULT) — corrupted API state/DoS-class at worst, not memory unsafety. Fix: keep byte counters in a single wide type (diff in row) / reject kbytes > INT_MAX up front.

Timeline

• 2026-09-02 Discovered during pass-2 audit of kern_xio.c (GLM 5.3). Known DF-0157-0160 re-verified still present, not re-reported.