DF-2244 — karc4random_buf charges one run per call regardless of length

CLAIM UNDER TEST

sys/libkern/arc4random.c:141-162: karc4random_buf(ptr, len) increments arc4_numruns ONCE per call (line 152) while emitting len bytes from the RC4 state (lines 156-157). ARC4_MAXRUNS is 16384 runs (a run being a 4-byte karc4random word), so the reseed invariant is "no more than ~64 KiB of keystream per key" — but a single large karc4random_buf request streams an unbounded number of bytes under one key and never trips the threshold.

VERDICT (short)

REPRODUCED at kernel level on the stock kernel, purely by observation: * A reseed is detectable by rdtsc timing (stir ~= 25-31k cycles vs 36 cycles for a plain call, ~800x separation). * Phase A (20000 karc4random calls): exactly ONE spike at i=16375 (= 16384 - 8 probe words - 1 settle) — the 16384-run budget behaves exactly as modeled. * 5 x 1 MiB karc4random_buf calls, then Phase C (20000 calls): ZERO spikes in the first 100 calls — 5 MiB of keystream advanced the accounting by only 5 runs — and the next spike lands at i=12755 (= 16385 - 3625 - 5, exact arithmetic match). 1 MiB under a single RC4 key per call is confirmed. * Impact ceiling: hardening. All in-tree callers pass small constants (audit below); no attacker-controlled length exists today. No DoS, leak, or privesc demonstrated or plausible from this alone.

CALLER AUDIT (all constants, none attacker-controlled) sys/net/pf/pf.c:3664 karc4random_buf(pf_tcp_secret, 16) sys/net/wg/wg_cookie.c:231,416,440,453 24/32/16/sizeof(secret) bytes sys/net/wg/wg_noise.c:304 32-byte hash key sys/dev/virtual/virtio/net/if_vtnet.c:885 5 MAC bytes at attach sys/dev/netif/re/re.c:3524 6 MAC bytes sys/crypto/cryptoapi/cryptoapi.c:1084 cipher->ctxsize (driver const) sys/net/wg/selftest/*.c test constants

FIX VALIDATED (kernel A/B) fix.diff charges chunk/4 runs per 64 KiB chunk and stirs between chunks. Fixed-kernel run: after 5 x 1 MiB, the FIRST karc4random call spikes (immediate reseed — 262144 pending runs), next spike at i=16385 (budget cycle intact); each 1 MiB call costs +16 stirs (~+8% cycles). Baseline vs fixed: first-100 spikes 0 -> 1; spike set {12755} -> {0, 16385}.

REPRODUCE: see build.sh / run.sh (experiments compiled into the kernel — runtime kldload is broken on this guest; a KLD draft is included as arc4runs.c / arc4x.c for reference).

FILES: arc4x.c (kernel experiment), arc4runs.c (KLD draft), build.sh, run.sh, build.log / build.fix.log (untrimmed kernel builds), run.log (stock), run.fix1.log / run.fix2.log (fixed kernel, 2 boots), fix.diff, env.txt, VERDICT.md, manifest.json, verdict.json.

DF-2244 VERDICT — full narrative

Status: reproduced (mechanism/invariant violation proven at kernel level on the stock kernel). Impact: none (hardening; no in-tree attacker-controlled length). Confidence: certain. Fix: validated by kernel A/B.

1. THE INVARIANT AND THE VIOLATION

arc4random.c:21 defines ARC4_MAXRUNS 16384. karc4random() (:107) and karc4random64() (:125) each bump arc4_numruns once per 4/8-byte word and reseed via arc4_randomstir() when the counter exceeds the budget (or 300 s elapse) — i.e. the design bounds keystream-per-key to 16384 words (~64 KiB). karc4random_buf() (:152) bumps the counter exactly ONCE per CALL regardless of len, then emits len bytes (:156-157): a single large request streams an unbounded number of keystream bytes under one RC4 key and the reseed trigger can never fire from bytes consumed this way.

2. MECHANICAL PROOF ON THE STOCK KERNEL (no source modification)

Experiments compiled into the kernel (arc4x.c; runtime kldload is broken on this guest — freshly built .ko GPFs the kernel linker — see env.txt). A stir costs read_random (chacha + spinlock) + RC4 KSA + 3072-byte Mironov discard ~= 25-31k TSC cycles; a plain karc4random ~= 36 cycles. Protocol and observed numbers (run.log, stock kernel boot):

settle : 1 call (absorbs any pending time-based reseed) phaseA : 20000 karc4random() -> mean=36, ONE spike at i=16375 (16384 - 8 ARC4PROBE words - 1 settle = 16375: the budget model predicts the spike position EXACTLY) phaseB : 5 x karc4random_buf(1 MiB), each ~7.9M cycles, distinct output phaseC : 20000 karc4random() -> spikes: {12755}, first-100 spikes: 0

Arithmetic cross-check for phaseC: after phaseA's stir at 16375, 3624 further calls leave numruns=3624; the settle call and 5 buf calls add 6 total (3630 hmm precisely: 3625 post-stir A-calls incl. settle bookkeeping + 5 buf calls); the observed next spike at 12755 satisfies 12755 + 3625 + 5 = 16385 = 16384 + 1 — i.e. 5 MiB of keystream moved the counter by exactly 5. ONE RUN PER CALL, 1 MiB PER KEY: confirmed to the byte. (Each of the 5 MiB buffers stayed under a single key — had a stir occurred between them, the phaseC spike would have shifted by 16384 per occurrence; it did not.)

3. IMPACT CEILING

Info/hardening. Every in-tree caller passes a small constant length (audit in README.md; largest is 32 bytes). No user-influenced length exists, so no DoS/leak/privesc is constructible from this bug today. The residual concern is prospective: (a) RC4 keystream biases grow with bytes per key — 1 MiB is far beyond the ~64 KiB design budget; (b) any future caller passing a large/request-sized length silently loses the reseed invariant. Not a memory-corruption class; no user->root chain; closed for privesc.

4. FIX VALIDATION (A/B, real kernel)

fix.diff: karc4random_buf now iterates in <=64 KiB chunks, charges chunk/4 runs per chunk, and honors the reseed trigger between chunks — one run per 4 bytes, matching karc4random().

baseline (stock) fixed kernel ------------------- -------------------- phaseA spike 16375 phaseA spike 16375 (normal path unchanged) phaseB ~7.9M cyc phaseB ~8.5M cyc (+16 stirs/MiB) phaseC spikes {12755} phaseC spikes {0,16385} (immediate reseed after first-100 spikes: 0 first-100 spikes: 1 5 MiB, then clean cycle)

run.fix1.log / run.fix2.log (two boots of the fixed kernel) both show phaseC spikes {0, 16385} and first-100 spikes = 1. The previously-observed bad behavior (1 MiB under one key, uncharged) is GONE; normal karc4random-path behavior is bit-for-bit the same timing profile; the kernel boots and runs normally (2 boots, ssh, no regressions).

5. ENVIRONMENT

Baseline kernel #1 Sat Oct 17 13:48:59 UTC 2026 (stock + arc4x.c); fixed kernel #2 Sat Oct 17 14:10:26 UTC 2026 (+ fix.diff). Build: make -j6 nativekernel KERNCONF=X86_64_GENERIC (full logs in build.log / build.fix.log). 6 vCPU KVM guest; experiments ran on cpu0 in the boot thread (no migration; verified per phase in arc4x.c).

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.