Zephyr Project up to 4.4.x Entropy Device random_entropy_device.c rand_get uninitialized resource

Summaryinfo

A vulnerability identified as critical has been detected in Zephyr Project Zephyr up to 4.4.x. This affects the function rand_get of the file subsys/random/random_entropy_device.c of the component Entropy Device. Performing a manipulation results in uninitialized resource. This vulnerability is identified as CVE-2026-87043. The attack can be initiated remotely. There is not any exploit available. You should upgrade the affected component.

Detailsinfo

A vulnerability was found in Zephyr Project Zephyr up to 4.4.x. It has been classified as critical. This affects the function rand_get of the file subsys/random/random_entropy_device.c of the component Entropy Device. The manipulation with an unknown input leads to a uninitialized resource vulnerability. CWE is classifying the issue as CWE-908. The product uses or accesses a resource that has not been initialized. This is going to have an impact on confidentiality, integrity, and availability. The summary by CVE is:

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'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(&ret, sizeof(ret)) and returns ret. The "not ready" 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'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). When this occurs, every non-cryptographic random value in the system is either a constant or stale memory. coap_next_token() in subsys/net/lib/coap/coap.c fills a static buffer, so every CoAP token becomes the same .bss constant; tcp_init_isn() in subsys/net/ip/tcp.c returns an uninitialized stack word as the TCP initial sequence number; DHCPv4/DHCPv6 transaction IDs, WebSocket masking keys and RTP SSRCs are similarly degraded, and arch/arm64/core/pac.c derives per-thread Pointer Authentication keys from the same source. Where the bytes are transmitted directly — SSH packet padding, the netmidi2 session nonce, a DTLS connection ID on builds without CONFIG_CSPRNG_ENABLED — stale caller stack or heap contents are disclosed on the wire. The fix initialises ret to -ENODEV and only calls entropy_get_entropy() when the device is ready, so the not-ready case now falls through to the timer fallback and the buffer is always written. The cryptographically secure path is unchanged: sys_csrand_get() still propagates the error to the caller and never silently degrades. An attacker cannot induce the unready state, but can observe and exploit the resulting non-random values remotely on an affected device.

It is possible to read the advisory at github.com. This vulnerability is uniquely identified as CVE-2026-87043 since 09/08/2026. The exploitability is told to be easy. It is possible to initiate the attack remotely. No form of authentication is needed for exploitation. Technical details of the vulnerability are known, but there is no available exploit.

Upgrading to version 4.5.0 eliminates this vulnerability.

Statistical analysis made it clear that VulDB provides the best quality for vulnerability data.

Productinfo

Type

• Project Management Software

Vendor

• Zephyr Project

Name

• Zephyr

Version

• 4.0
• 4.1
• 4.2
• 4.3
• 4.4

CPE 2.3info

• 🔒
• 🔒
• 🔒

CPE 2.2info

• 🔒
• 🔒
• 🔒

CVSSv4info

CVSSv3info

CVSSv2info

Exploitinginfo

Threat Intelligenceinfo

Countermeasuresinfo

Timelineinfo

Sourcesinfo

Entryinfo

Statistical analysis made it clear that VulDB provides the best quality for vulnerability data.

Discussion