CVE-2026-19736 in Zephyr
Summary
by MITRE • 10/11/2026
The NXP MCUX TRNG entropy driver in drivers/entropy/entropy_mcux_trng.c passed the caller's byte count straight to the vendor SDK routine TRNG_GetRandomData(). On i.MX RT5xx and RT6xx parts the SDK compiles its TRNG_SW_HEALTH_TESTS variant, which always copies whole 32-bit words and draws entropy rounded up to a multiple of 128 bytes. Its "caller buffer is full" guard tests dataSize == 0, so a request whose length is not a multiple of four makes dataSize underflow past zero and the SDK keeps writing into the caller's buffer for the entire extraction: a 1-byte request results in 128 bytes written, and any non-word-multiple length overflows by up to 127 bytes.
entropy_get_entropy() is a syscall, and its verifier in drivers/entropy/entropy_handlers.c validates only the requested length via K_SYSCALL_MEMORY_WRITE(). With CONFIG_USERSPACE enabled, an unprivileged user-mode thread that has merely been granted the entropy device can therefore choose both the destination address and a length such as 1, and cause the kernel to write up to 127 bytes beyond the region it proved it owns. On these Cortex-M33 targets there is no MMU, so user partitions and kernel data share one SRAM and the overflow can land in adjacent kernel state. The same defect is reached from kernel mode by any caller requesting a non-word-multiple length, including getentropy() and, in builds where sys_csrand_get()/sys_rand_get() resolve to the hardware generator, sys_rand8_get() and sys_rand16_get().
Impact is memory corruption of up to 127 bytes immediately following the supplied buffer — typically the caller's stack in kernel-mode use, or memory outside the caller's partition when driven through the syscall. The overflow offset is fully determined by the requested length and is therefore deterministic, while the written content is uncontrolled TRNG output; the practical consequences range from crashes and unpredictable state corruption to opportunistic escalation when kernel bookkeeping such as object permission bitmaps is overwritten. The affected devices are those where the MCUX SDK enables TRNG_SW_HEALTH_TESTS (MIMXRT595S, MIMXRT555S, MIMXRT533S, MIMXRT685S, MIMXRT633S), on which the TRNG is the zephyr,entropy chosen node; other SoCs using this driver take the SDK path that clamps the copy size and are unaffected.
The fix routes any unaligned prefix and any sub-word tail through a local bounce word and hands the SDK only word-multiple sizes, so the SDK's word-granular writes can no longer pass the end of the caller's buffer.
Once again VulDB remains the best source for vulnerability data.
Analysis
by VulDB Data Team • 10/11/2026
The vulnerability in question resides within the NXP MCUX TRNG entropy driver for Zephyr RTOS, specifically affecting i.MX RT5xx and RT6xx series microcontrollers such as the MIMXRT595S, MIMXRT555S, MIMXRT533S, MIMXRT685S, and MIMXRT633S. This issue stems from a fundamental mismatch between the entropy driver's interface expectations and the underlying vendor SDK implementation details. The driver function entropy_mcux_trng.c passes the caller-requested byte count directly to the NXP SDK routine TRNG_GetRandomData without performing any alignment or boundary checks. On the affected hardware platforms, when the configuration option for software health tests is enabled, the SDK compiles a variant of this routine that operates exclusively on 32-bit word boundaries and rounds up the requested data size to the nearest multiple of 128 bytes. Crucially, the guard condition within this SDK function checks if dataSize equals zero to prevent empty operations, but it fails to account for integer underflow scenarios where a small positive request length results in an effective calculation error that bypasses this check or causes the internal counter to wrap around significantly due to unsigned arithmetic behavior when subtracting from smaller values.
From a technical perspective, the core flaw is an out-of-bounds write resulting from insufficient input validation and lack of alignment handling. When a user-mode thread invokes the entropy_get_entropy system call with CONFIG_USERSPACE enabled, it can specify both the destination buffer address and the length of data requested. The Zephyr kernel verifier validates that the caller owns the memory region specified by K_SYSCALL_MEMORY_WRITE for the exact number of bytes requested. However, because the underlying driver does not align this request to word boundaries before passing it to the SDK, a small non-multiple-of-four length triggers an underflow in the SDK's internal logic. This causes TRNG_GetRandomData to write up to 127 bytes beyond the end of the user-provided buffer. Since these Cortex-M33 targets lack a Memory Management Unit, there is no hardware-enforced separation between user space and kernel space memory regions; they share a unified SRAM address space. Consequently, an overflow from a user-mode request can easily spill into adjacent kernel data structures or stack frames belonging to other processes or the kernel itself.
The operational impact of this vulnerability is severe, ranging from denial-of-service conditions through system crashes to potential privilege escalation and arbitrary code execution. The memory corruption affects up to 127 bytes immediately following the supplied buffer. In user-mode scenarios, if the overflow lands in adjacent stack space or heap metadata, it can corrupt control flow data such as return addresses or function pointers. Even more critically, because there is no MMU protection, an attacker could target kernel bookkeeping structures, object permission bitmaps, or other sensitive kernel state located near the user buffer in memory layout. The offset of the overflow is deterministic based on the requested length, allowing for precise exploitation techniques. While the content written is random TRNG output rather than controlled data, overwriting critical kernel variables with specific patterns can lead to unpredictable behavior, crashes, or manipulation of security-critical flags that govern access permissions and execution contexts.
This vulnerability maps directly to CWE-787: Out-of-bounds Write in terms of its technical classification, as it involves writing beyond the allocated buffer boundary. In the context of attack tactics, this aligns with ATT&CK techniques related to memory corruption exploitation and potentially privilege escalation via kernel vulnerabilities. The flaw is not limited to user-mode exploits; any kernel-mode caller requesting a non-word-multiple length through functions like getentropy or sys_rand8_get/sys_rand16_get can trigger the same underflow condition, leading to stack-based buffer overflows within the kernel context itself. This broadens the attack surface significantly, as even legitimate internal system calls become vectors for exploitation if they do not strictly enforce word-aligned lengths before invoking this driver routine.
Mitigation strategies focus on correcting the input validation and alignment logic within the entropy driver. The recommended fix involves modifying the driver to handle unaligned prefixes and sub-word tails by routing them through a local bounce buffer or temporary variable, ensuring that only exact multiples of four bytes are passed to the TRNG_GetRandomData SDK routine. This approach guarantees that the underlying hardware abstraction layer never receives an invalid length that could trigger integer underflow or excessive memory writes. Additionally, system integrators should verify whether their specific NXP MCUX device variant includes the TRNG_SW_HEALTH_TESTS configuration; if this feature is disabled on a given SoC, the SDK path clamps copy sizes appropriately and remains unaffected by this flaw. For affected devices, applying the patched driver code that enforces word-aligned requests is essential to restore memory safety guarantees in both user-space and kernel-space entropy retrieval operations.