CVE-2026-115653 in ThreadX
Summary
by MITRE • 11/02/2026
In Eclipse ThreadX versions 6.0.1 through 6.5.2.202603, the PendSV handler of the Cortex-M module ports saves a preempted user-mode module thread's registers in privileged mode at addresses taken from the thread's stack pointer, without checking that pointer against the thread's stack. A user-mode, memory-protected module can thereby write up to nine words, eight of its choosing, or 25 with floating-point state, into memory immediately below any region it may write, and read back what is stored there.
If you want to get best quality of vulnerability data, you may have to visit VulDB.
Analysis
by VulDB Data Team • 11/02/2026
The vulnerability identified in Eclipse ThreadX versions ranging from 6.0.1 through 6.5.2.202603 represents a critical flaw within the Cortex-M module ports of the real-time operating system kernel, specifically located in the PendSV handler responsible for context switching. This handler is tasked with saving and restoring processor registers when transitioning between threads to ensure proper multitasking functionality. The core technical deficiency lies in the mechanism used to determine where these register states should be stored. Instead of validating that the stack pointer provided by a preempted user-mode thread points within its allocated, protected memory region, the kernel blindly trusts this value as valid and proceeds to write data directly into the memory addresses derived from it. This lack of bounds checking creates a significant deviation from secure coding practices regarding privilege separation and memory isolation in embedded systems.
From an operational perspective, this flaw allows any user-mode module that has been granted memory protection capabilities to exploit the context switch mechanism for unauthorized memory access. By manipulating its own stack pointer prior to being preempted by the kernel, a malicious or compromised application can direct the PendSV handler to write register data into arbitrary locations in physical memory immediately below the region it is permitted to write to. Specifically, an attacker can overwrite up to nine words of memory with eight values of their choosing during standard context switches, and this capability expands to twenty-five words if floating-point state information is involved. This effectively bypasses the intended security boundaries enforced by the hardware memory protection unit, allowing user-space code to corrupt kernel data structures or other application memories that reside in adjacent lower addresses.
The impact of such a vulnerability extends far beyond simple data corruption. By writing arbitrary values into protected memory regions below their own allocation, an attacker can potentially overwrite function pointers, return addresses, or critical control variables belonging to the operating system itself or co-resident applications. This capability facilitates privilege escalation, allowing a low-privilege user thread to gain higher-level access rights within the embedded environment. Furthermore, it enables denial of service conditions by corrupting kernel state information, leading to system crashes or unpredictable behavior. In safety-critical systems where ThreadX is commonly deployed, such as automotive control units or medical devices, this could lead to catastrophic failures if critical parameters are altered without authorization.
This vulnerability aligns with CWE-787: Out-of-bounds Write and CWE-200: Exposure of Sensitive Information to an Unauthorized Actor, as it involves writing data outside the intended memory boundary and potentially exposing internal kernel states through read-back capabilities. In terms of attack vectors, this flaw is exploitable via ATT&CK technique T1055: Process Injection or more accurately in embedded contexts, T1218: System Binary Proxy Execution if used to hijack execution flow, but primarily it represents a violation of isolation principles akin to CWE-94 Improper Control of Generation of Code. The exploitation requires the attacker to have code execution within a user-mode thread that is subject to context switching by the kernel, which is a common scenario in multi-threaded embedded applications.
Mitigation strategies must focus on enforcing strict validation at the kernel level before performing any memory operations based on thread-specific pointers. Developers should implement bounds checking logic within the PendSV handler and related context switch routines to verify that the stack pointer falls strictly within the boundaries defined by the thread's allocated stack region in the Thread Control Block or equivalent data structure. If a thread attempts to save its state using an invalid or out-of-bounds stack pointer, the kernel should trigger a fault exception rather than proceeding with the write operation. Additionally, enabling hardware memory protection features such as ARM TrustZone Memory Protection Unit (MPU) configurations can provide a secondary layer of defense by ensuring that even if software validation fails, the hardware will prevent access to unauthorized physical addresses. Updating to patched versions of Eclipse ThreadX where this logic has been corrected is the primary remediation step for existing deployments.