CVE-2026-95111: Module queue front-send validates a word count as a byte count
A memory-protected ThreadX module's queue request reaches the Module Manager's dispatch layer, which decides how much of the module's buffer the privileged queue copy may touch and hands that extent to the module port's range check. A queue's txqueuemessagesize is a count of ULONGs and the copy moves that many words, so the extent is messagesize sizeof(ULONG) bytes.
The front-send dispatcher passed the word count itself. txqueuesend and txqueuereceive, either side of it in the same header, have always multiplied.
A source buffer ending messagesize bytes into memory the module may read was therefore accepted, and txequeuefrontsend then read messagesize sizeof(ULONG) bytes from it in privileged mode — 3 messagesize bytes past the end of what the module is allowed to read. The words are written into the queue's message area, so a module that can receive from that queue reads them back.
Affected Software
Event History
Frequently Asked Questions
Which deployments are exposed to this issue?
Deployments using memory-protected ThreadX modules are exposed when a module submits a queue front-send request that reaches the Module Manager dispatch layer. The issue concerns the front-send path; the adjacent queue send and receive paths multiply the message size correctly.
What access does an attacker need to exploit it?
An attacker needs the ability to cause a memory-protected module to issue a queue front-send request with a source buffer positioned near the end of memory that the module is allowed to read. No user interaction is required.
What can an attacker obtain through the out-of-bounds read?
The privileged queue copy can read 3 times the queue message size in bytes beyond the range accepted by the incorrect check. Those words are placed in the queue message area, where a module able to receive from that queue can read them back.