https://db.gcve.eu Contains only the most 10 recent entries. http://www.rssboard.org/rss-specification python-feedgen en Sat, 07 Nov 2026 05:18:56 +0000 https://db.gcve.eu/vuln/fkie_cve-2026-87043 <p>The entropy-device random number generator in subsys/random/random_entropy_device.c returned early with -ENODEV from rand_get() as soon as device_is_ready() failed, before reaching the non-cryptographic system-timer fallback further down the same function. Because z_impl_sys_rand_get() returns void and discards that error — and the public sys_rand_get() syscall is itself declared void, so it cannot report failure — the caller&#39;s output buffer was left untouched and its previous contents were handed back as random data. The thin wrappers make this a plain uninitialized read: sys_rand32_get() declares uint32_t ret;, calls sys_rand_get(&amp;ret, sizeof(ret)) and returns ret.</p> <p>The &#34;not ready&#34; state is a normal runtime condition rather than a fault. Entropy drivers initialise at PRE_KERNEL_1 with CONFIG_ENTROPY_INIT_PRIORITY (default 50), so any earlier initialiser — kernel objects run at priority 30 — observes an unready device; the sibling generator subsys/random/random_xoshiro128.c and z_early_rand_get() in kernel/init.c both already carried an explicit timer fallback for exactly this case. The state is also permanent for the boot when an entropy driver&#39;s init hook fails, which several in-tree drivers can do on real hardware (entropy_stm32 on an RNG clock configuration error, entropy_psa_crypto when psa_crypto_init() fails, entropy_nrf_cracen, entropy_esp32, entropy_virtio).</p> <p>When this occurs, every non-cryptographic random value in the system is either a constant or stale memory.…</p> <p>The entropy-device random number generator in subsys/random/random_entropy_device.c returned early with -ENODEV from rand_get() as soon as device_is_ready() failed, before reaching the non-cryptographic system-timer fallback further down the same function. Because z_impl_sys_rand_get() returns void and discards that error — and the public sys_rand_get() syscall is itself declared void, so it cannot report failure — the caller&#39;s output buffer was left untouched and its previous contents were handed back as random data. The thin wrappers make this a plain uninitialized read: sys_rand32_get() declares uint32_t ret;, calls sys_rand_get(&amp;ret, sizeof(ret)) and returns ret.</p> <p>The &#34;not ready&#34; state is a normal runtime condition rather than a fault. Entropy drivers initialise at PRE_KERNEL_1 with CONFIG_ENTROPY_INIT_PRIORITY (default 50), so any earlier initialiser — kernel objects run at priority 30 — observes an unready device; the sibling generator subsys/random/random_xoshiro128.c and z_early_rand_get() in kernel/init.c both already carried an explicit timer fallback for exactly this case. The state is also permanent for the boot when an entropy driver&#39;s init hook fails, which several in-tree drivers can do on real hardware (entropy_stm32 on an RNG clock configuration error, entropy_psa_crypto when psa_crypto_init() fails, entropy_nrf_cracen, entropy_esp32, entropy_virtio).</p> <p>When this occurs, every non-cryptographic random value in the system is either a constant or stale memory.…</p> https://db.gcve.eu/vuln/fkie_cve-2026-87043