DF-0220 — PoC: Predictable RNG pre-reseed claim (verification)

Finding: findings/DF-0220-csprng-predictable-rng-pre-reseed.md Claim: /dev/urandom, getrandom(2), and kern.random return a deterministic all-zero-key ChaCha20 keystream before the first Fortuna reseed — identical across independent boots.

Verdict (re-verified 2026-07-03): NOT REPRODUCED. See VERDICT.md for the full root-cause trace.

Files

Build

./build.sh

(equivalent to cc -O2 -o rand_probe rand_probe.c && cc -O2 -o ref_keystream ref_keystream.c)

Run

./run.sh           # single-boot probe; prints hex of 4 RNG sources + uptime
./ref_keystream 64 # prints the degenerate all-zero pre-reseed keystream

Expected (claim TRUE / bug present)

On two (or more) independent fresh boots, the 64-byte /dev/urandom (and getrandom, kern.random) outputs would be byte-for-byte identical to each other AND identical to ref_keystream's output (the degenerate pre-reseed stream). With sysctl kern.rand_mode=csprng, /dev/urandom would return all zero bytes.

Actual (on DragonFly master DEV 6.5-DEVELOPMENT #0)

On three independent fresh vm.sh reset with-src boots the outputs are completely different (3 boots pairwise differ in 64/64 bytes for every source) and never match the all-zero reference. With rand_mode=csprng, /dev/urandom returns non-zero, varying bytes — proving the csprng cipher context is already keyed (reseeded) before any userspace read. The claim does not reproduce. See VERDICT.md and leak_sample.txt for the root cause (the per-CPU globaldata entropy feed reseeds pool[0] during rand_initialize, a kernel SYSINIT that runs before init(8)).

Reproduce across boots (the decisive test)

dfbsd-qemu/vm.sh reset with-src
# redeploy + build (disk is reverted by reset)
scp -F dfbsd-qemu/config rand_probe.c ref_keystream.c dfbsd-maxx:poc/DF-0220/
dfbsd-qemu/vm.sh run_user 'cd poc/DF-0220 && cc -O2 -o rand_probe rand_probe.c && ./rand_probe' > boot1.txt
dfbsd-qemu/vm.sh reset with-src
scp -F dfbsd-qemu/config rand_probe.c ref_keystream.c dfbsd-maxx:poc/DF-0220/
dfbsd-qemu/vm.sh run_user 'cd poc/DF-0220 && cc -O2 -o rand_probe rand_probe.c && ./rand_probe' > boot2.txt
# repeat for boot3, then diff /dev/urandom sections:
diff <(sed -n '/\/dev\/urandom/,/^$/p' boot1.txt) \
     <(sed -n '/\/dev\/urandom/,/^$/p' boot2.txt)   # differs => not reproducible

DF-0220 — VERDICT

Finding: Predictable RNG: /dev/urandom, getrandom(2), and kern.random return a deterministic ChaCha20 keystream (zero key) before the first reseed, identical across independent boots. (Severity High, Confidence "certain".)

Verdict: NOT REPRODUCED (the exploitable condition does not manifest on DragonFly master DEV 6.5-DEVELOPMENT #0; the finding's premise about pool[0] entropy is wrong — it omits the per-CPU globaldata feed that lands in pool[0] during rand_initialize, before userspace).

Re-verified 2026-07-03 on the audit-source kernel 6.5-DEVELOPMENT #0: Thu Jul 2 06:02:54 UTC 2026 (unpatched).

What is genuinely true in the claim (confirmed by source read)

1. The readiness gate is bypassed for unlimited readers. sys/kern/subr_csprng.c:146: c if ((flags & CSPRNG_UNLIMITED) == 0 && state->reseed_cnt == 0) { ssleep(state, &state->spin, 0, "csprngrsd", 0); goto again; } Only NON-unlimited readers block when reseed_cnt == 0. /dev/urandom, getrandom(2), kern.random, and in-kernel arc4random all reach csprng_get_random with CSPRNG_UNLIMITED (sys/kern/kern_nrandom.c:702-703 and :710-711, reached from read_random(...,1) at kern_nrandom.c:739 and :770, and sys/libkern/arc4random.c:60). So the gate genuinely does not protect them.

2. The cipher context is never keyed at init. csprng_init (subr_csprng.c:84-85) does bzero(state->key, ...) and bzero(&state->cipher_ctx, ...) and never calls chacha_keysetup. So IF chacha_encrypt_bytes (subr_csprng.c:155) ran while reseed_cnt == 0, it would run on an all-zero chacha_ctx (all 16 input words zero, including the 4 sigma-constant words that keysetup normally writes).

3. The all-zero chacha state is a fixed point — the degenerate "keystream" is all zeros. The chacha quarterround uses only PLUS, XOR, ROTATE. With every input word 0, every operation yields 0, so after 20 rounds and the final add all 16 output words are still 0. ref_keystream.c reproduces the kernel's exact transform on the all-zero state and emits 64 bytes of 0x00. (The finding's description "ChaCha20(key=0^32, counter=0^16)" is therefore inaccurate: that variant still has the non-zero sigma constants at input[0..3] and would be non-zero; the real degenerate output is all-zeros.)

So the code pattern the finding describes is real: an unlimited reader that reached csprng_get_random while reseed_cnt == 0 would receive all-zero bytes from the csprng (XORed with IBAA in default mixed mode).

Why it does NOT reproduce on this kernel

The finding's entire exploitability hinges on a window in which reseed_cnt == 0 and a reader obtains output. That window does not exist on master DEV, because the cipher is keyed during rand_initialize() — a kernel SYSINIT that runs before init(8), i.e. before any userspace read is possible.

SYSINIT ordering (sys/sys/kernel.h): - rand_initialize is registered at SI_BOOT2_POST_SMP = 0x1cc0000, SI_ORDER_SECOND (sys/kern/kern_nrandom.c:562). - init(8) is launched at SI_SUB_KTHREAD_INIT = 0xe000000 (kernel.h:216), ~0xc340000 subsystem-ticks later. Userspace cannot read /dev/urandom until then.

Trace of rand_initialize (sys/kern/kern_nrandom.c:485-560), per CPU: 1. csprng_init(state) (:507) — key=0, ctx=0, reseed_cnt=0. 2. Timing loop: 128 csprng feeds of 8 B each via RAND_SRC_TIMING (:517-531). csprng_add_entropy routes by pool_id = src_pool_idx[src_id & 0xff]++ & 0x1f (subr_csprng.c:272-273); src_pool_idx[0x02] cycles 0..31, so each pool gets ~4 feeds. pool[0] receives ~32 B from timing. This is the only entropy the finding considered, and on that basis alone its "pool[0] < 96 bytes" claim would hold. 3. The feed the finding omits (kern_nrandom.c:539-543): c state->inject_counter[RAND_SRC_THREAD2] = 0; add_buffer_randomness_state(state, (void *)rgd, sizeof(*rgd), RAND_SRC_THREAD2); RAND_SRC_THREAD2 = 0x0c (sys/sys/random.h:89). inject_counter[0x0c] starts at 0, so ++ makes it 1 → ic & 1 branch in add_buffer_randomness_state (kern_nrandom.c:614) calls csprng_add_entropy(state, 0x0c & RAND_SRC_MASK, ...). src_pool_idx[0x0c] starts at 0 → pool_id = 0. So sizeof(struct globaldata) lands entirely in pool[0]. Verified via DWARF + gdb on /boot/kernel/kernel.debug: sizeof(struct globaldata) = 14976 bytes (gd_reserved02B[200] alone is 1600 B; plus gd_idlethread, gd_slab/gd_kmslab, gd_systimerq, three gd_*clock systimers, etc.). pool[0] therefore receives 32 (timing) + 14976 (rgd) ≈ 15008 bytes — far beyond MIN_POOL_SIZE = 96. 4. read_random(buf, sizeof(buf), 1) (kern_nrandom.c:558) → csprng_get_random → ratecheck() fires on the first call (subr_csprng.c:134-135) → csprng_reseed (subr_csprng.c:176). The guard state->pool[0].bytes < MIN_POOL_SIZE (:188) passes → reseed_cnt becomes 1 (:201), a fresh key is derived from the pools via SHA-256 (:228), and chacha_keysetup + chacha_ivsetup finally key the cipher (:231,235).

From this point — still inside the kernel SYSINIT, before init(8) — every subsequent read sees a properly-keyed csprng. There is no userspace-reachable pre-reseed window. Even in-kernel arc4random's first stir happens after this, so it keys from good data.

Empirical proof (3 independent fresh boots; full data in leak_sample.txt,

boot1_probe.txt, boot2_probe.txt, boot3_probe.txt)

Three independent vm.sh reset with-src boots, probe run as soon as ssh comes up. (Disk is reverted on each reset, so each boot is independent.)

Output is non-deterministic across boots and never matches the degenerate keystream.

Decisive secondary test — isolate the csprng with sysctl kern.rand_mode=csprng (raw csprng, no IBAA mixing): three consecutive reads return non-zero, distinct bytes. If reseed_cnt were still 0, csprng-only mode would emit the all-zero fixed-point keystream. It does not → the cipher is keyed before userspace.

Classification

Case (a) false-premise / (d) not reachable on this kernel. The finding's threat model assumes a userspace-observable pre-reseed window, but the per-CPU globaldata entropy feed (kern_nrandom.c:539-543) closes that window during rand_initialize (kernel SYSINIT SI_BOOT2_POST_SMP), before init. The cross-boot determinism the finding predicts is empirically absent across 3 independent fresh boots.

The underlying gate-bypass + never-keyed-cipher pattern is a real defense-in-depth gap (if pool[0] routing or the rgd feed ever changed, the all-zero leak would resurface for unlimited readers), so fix.diff provides a targeted hardening — gate unlimited readers too when reseed_cnt == 0 (return 0 bytes, do not emit the degenerate keystream) — but it is hardening, not a fix for a reproduced vuln. Phase 8 single-fix-kernel build/boot is therefore not applicable (the patched kernel would behave identically to the unpatched one, since reseed_cnt is already > 0 before any userspace read; there is no "before/after" bad-behavior contrast to demonstrate).

PoC changes

rand_probe.c (multi-source RNG reader + uptime) and ref_keystream.c (degenerate-keystream reference that reproduces the kernel's exact chacha transform on the all-zero state) were authored by the prior runner. This re-verification made no source changes — both programs build and run unchanged. The only file refreshed in this pass was fix.diff: the prior version had a bogus index 0000000..1111111 git-header line that broke patch -p1 from /usr/src; it has been regenerated with proper diff --git / --- / +++ headers (hunk content unchanged) and verified to apply cleanly (patch -p1 --dry-run → rc=0, hunk #1 succeeded at line 138) and compile (cc -fsyntax-only of the patched TU → rc=0). Evidence files refreshed: boot1_probe.txt, boot2_probe.txt, boot3_probe.txt, leak_sample.txt, env.txt, manifest.json, this VERDICT.md.