rand_thread_loop feeds generator output back into the entropy pools, so the MIN_POOL_SIZE reseed gate can be satisfied with zero external entropy

Summary

Every ~100-200ms the random helper thread adds the PREVIOUS iteration's read_random() output (32 bytes) into the same state's pools as RAND_SRC_THREAD1, plus per-cpu globaldata counters. csprng_reseed's only freshness gate is pool[0].bytes >= MIN_POOL_SIZE — a raw byte counter with no entropy estimate. Under total external-entropy starvation (quiet appliance/vkernel, no RDRAND/virtio-rng/keyboard) the self-feedback and predictable per-cpu counters keep the byte count above threshold forever, so reseeds keep deriving new keys purely from old generator state and boot-time timing; /dev/random's limited reads never stall and the CSPRNG presents a continuously-reseeded facade while its key evolution is a deterministic function of the initial weak seed. The entropy-starvation-masking complement to DF-0220 (pre-first-reseed window) and DF-0068 (IBAA gate) — a distinct post-reseed self-feed mechanism. On entropy-starved machines long-term keys (TCP ISN secrets, kern_uuid, sppp seeds) continue to be derived with no fresh unpredictability while operators believe the blocking gate guarantees entropy; the failure is silent and unbounded in time.

Recommended fix

Never credit self-generated or low-assurance data toward the reseed gate: track an estimated-entropy counter per pool incremented only by external sources, gate reseeds on that counter, and feed generator chaining through a separate non-credited channel (add_buffer_randomness_state_nocredit) — sketch diff in the row above.

Timeline

• 2026-08-31 Discovered during pass-2 audit of kern_nrandom.c (GLM 5.3).