CVE-2026-102757: High severity Microsoft Azure Rtos Threadx vulnerability
An unprivileged, memory-protected ThreadX module can have the kernel read and write memory at addresses of its choosing, in privileged mode, and can use that to clear the MPU enable bit and remove its own isolation boundary.
The Module Manager decided whether a privileged service could dereference an object address a module named by asking only whether that address fell outside the module. The manager's object pool is outside every module, so the test was satisfied by an address shifted into the interior of one of the module's own privileged allocations, which denotes no object at all. The bytes such an address presents as a control block are bytes the module put there through ordinary create and set services, so the control block ID at the front of them could be made to read as any type the module chose, and the txe layer's ID test then agreed. The reported chain uses that to reach a privileged memset across an attacker-chosen range.
Affected Software
Event History
Frequently Asked Questions
Which deployments are exposed?
Deployments that run unprivileged, memory-protected ThreadX modules are affected by this issue. The attack relies on the Module Manager handling object addresses supplied by such a module and on privileged allocations within the module's address space.
What does an attacker need to exploit this?
An attacker needs the ability to execute code in an unprivileged ThreadX module. The module can use ordinary create and set services to prepare attacker-controlled bytes that are interpreted as a valid control block, then use a crafted address to reach a privileged memory operation.
What is the practical impact after exploitation?
The reported exploitation chain reaches a privileged memset over an attacker-chosen memory range. This can be used to clear the MPU enable bit, removing the attacking module's isolation boundary.