CVE-2026-19736: Out-of-bounds write in the NXP MCUX TRNG entropy driver for non-word-multiple request lengths
The NXP MCUX TRNG entropy driver in drivers/entropy/entropymcuxtrng.c passed the caller's byte count straight to the vendor SDK routine TRNGGetRandomData(). On i.MX RT5xx and RT6xx parts the SDK compiles its TRNGSWHEALTHTESTS 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.
entropygetentropy() is a syscall, and its verifier in drivers/entropy/entropyhandlers.c validates only the requested length via KSYSCALLMEMORYWRITE(). With CONFIGUSERSPACE 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 syscsrandget()/sysrandget() resolve to the hardware generator, sysrand8get() and sysrand16get().
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 TRNGSWHEALTHTESTS (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.
Affected Software
Event History
Frequently Asked Questions
Which deployments are exposed to unprivileged exploitation?
Exposure requires an i.MX RT5xx or RT6xx target using the affected MCUX TRNG SDK variant, CONFIG_USERSPACE enabled, and an unprivileged user-mode thread that has been granted access to the entropy device. The thread must be able to invoke the entropy syscall.
What input is needed to trigger the unsafe write?
The caller supplies a destination buffer and a requested entropy length that is not a multiple of four bytes. A one-byte request can cause 128 bytes to be written, while other non-word-multiple requests can overflow the validated destination region by up to 127 bytes.
How can I assess whether a system may already be vulnerable?
Check whether the device is an i.MX RT5xx or RT6xx system and whether its Zephyr configuration enables userspace and grants entropy-device access to unprivileged threads. Calls requesting entropy lengths not divisible by four are the relevant trigger condition.