Description

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.

Executive Summary

Technical Details

Mitigations

References

Additional Metadata

{
  "score": "7.8",
  "pubDate": "2026-10-11T18:16:58.810Z",
  "pubdate": "2026-10-11T18:16:58.810Z",
  "executiveSummary": "A heap/stack-based buffer overflow vulnerability exists in the NXP MCUX TRNG entropy driver used in Zephyr RTOS, specifically affecting i.MX RT5xx and RT6xx series microcontrollers.\nThe vulnerability originates from an integer underflow in the TRNG_GetRandomData() routine within the NXP SDK, triggered when an unaligned buffer size is provided.\nThis flaw allows an attacker to overwrite up to 127 bytes of memory beyond the intended destination buffer, potentially corrupting kernel data structures or user-mode partitions.\nBecause the platform lacks an MMU, the lack of memory isolation exacerbates the risk, allowing memory corruption to escalate to arbitrary kernel state manipulation or system crashes.\nThe vulnerability is reachable through the entropy_get_entropy() syscall, enabling an unprivileged user-mode thread with access to the entropy device to compromise kernel integrity.\nRisk is significant due to the deterministic nature of the overwrite, despite the payload being unpredictable TRNG output.",
  "technicalDetails": "The root cause is a mismatch between the caller-provided buffer size and the internal processing requirements of the NXP SDK's TRNG_SW_HEALTH_TESTS variant. On i.MX RT5xx and RT6xx hardware, the SDK mandates that entropy data be processed in whole 32-bit words, with the total extraction volume rounded up to a multiple of 128 bytes.\nThe SDK includes a 'caller buffer is full' guard condition that checks if 'dataSize == 0'. When a request for a non-word-multiple length (e.g., 1 byte) is passed to the routine, the internal calculation results in an integer underflow. Instead of terminating, the SDK treats the underflow as a large positive value, causing the routine to continue writing TRNG output until the full 128-byte block is exhausted, effectively overflowing the destination buffer.\nIn the Zephyr kernel, the entropy_get_entropy() function is exposed as a syscall. The associated verifier in drivers/entropy/entropy_handlers.c validates only the buffer length via K_SYSCALL_MEMORY_WRITE() before passing the buffer address and size to the driver. The driver fails to sanitize the requested size to ensure it aligns with the SDK's word-processing constraints.\nExploitation involves an unprivileged user-mode thread requesting a sub-word buffer size (e.g., 1 byte). The syscall verifier validates that the user owns the 1-byte buffer, but the subsequent driver call triggers an overflow of up to 127 bytes. Because Cortex-M33 platforms lack an MMU, there is no hardware-enforced protection between the user-mode thread and kernel data regions. An attacker can use this to overwrite adjacent kernel state, such as object permission bitmaps, leading to privilege escalation.\nThe attack is deterministic: the overflow offset is controlled by the user's chosen length, and the write occurs immediately following the user-supplied buffer. While the content written is randomized TRNG output, the ability to predictably corrupt kernel bookkeeping or stack frames provides an attacker with a high-probability vector for system compromise or arbitrary code execution within the kernel context."
}