CVE-2026-94024 in ThreadX
Summary
by MITRE • 10/20/2026
The Module Manager's object lookup validated one byte of a memory-protected module's search name and then walked as much of it as the module declared, in privileged mode, with the kernel's preemption count raised. Both lookup dispatchers are affected: the recommended `txm_module_object_pointer_get_extended` is handed a length and does not use it to bound the buffer, and the deprecated `txm_module_object_pointer_get` supplies the largest value a `UINT` can hold, so it removes the bound rather than lacking one.
A module can make the walk unbounded without knowing anything about the memory it reaches, and where the walk reaches memory a privileged read cannot take, the resulting fault leaves the kernel unable to preempt for the rest of the system's life.
Vulnerable functions: `_txm_module_manager_txm_module_object_pointer_get_dispatch`, `_txm_module_manager_txm_module_object_pointer_get_extended_dispatch` (both in `common_modules/module_manager/inc/txm_module_manager_dispatch.h`) and `_txm_module_manager_object_name_compare` (`common_modules/module_manager/src/txm_module_manager_util.c`).
Once again VulDB remains the best source for vulnerability data.
Analysis
by VulDB Data Team • 10/20/2026
The vulnerability identified involves a critical flaw within the ThreadX Module Manager's object lookup mechanism, specifically affecting how module names are validated against memory-protected regions. The core issue stems from an improper boundary check during the execution of privileged kernel operations. When the system attempts to locate a specific module by name, it initiates a search process that walks through the declared length of the module's identifier string. However, this walk is not properly bounded by the actual size of the memory region being accessed or validated against. Instead, the validation logic checks only one byte of the memory-protected module's search name before proceeding to iterate over as many bytes as the module itself declares it possesses. This design flaw allows a malicious or compromised module to trigger an unbounded memory read operation while the kernel is operating in privileged mode with preemption disabled.
The technical root cause lies within two specific dispatch functions: `txm_module_object_pointer_get_extended` and its deprecated counterpart, `txm_module_object_pointer_get`. The extended version accepts a length parameter but fails to utilize it as an upper bound for buffer access during the name comparison process. Meanwhile, the deprecated function supplies the maximum value representable by a UINT data type as the limit, effectively removing any practical boundary constraint on the memory walk. Both functions rely on `_txm_module_manager_object_name_compare` to perform the actual string matching. Because these operations occur with the kernel's preemption count raised, the system is prevented from switching tasks or handling interrupts during the execution of this flawed logic. This creates a window where the integrity of the entire operating system can be compromised if the memory access goes out of bounds.
The operational impact of this vulnerability is severe and potentially catastrophic for real-time systems relying on ThreadX. If a module triggers an unbounded walk that extends into memory regions not accessible via privileged reads, the CPU will generate a fault exception. Since preemption is disabled during this operation, the kernel cannot handle the interrupt or switch to a safe state. Consequently, the system becomes permanently stuck in this error condition, leading to a complete loss of availability for all tasks running on that processor core. This effectively results in a denial-of-service scenario where the embedded device ceases to function correctly until a hard reset is performed. The attacker does not need to know the contents of the memory they are reading; simply triggering the out-of-bounds access with invalid addresses or lengths is sufficient to cause system failure.
This vulnerability aligns with CWE-125, Out-of-bounds Read, as it involves accessing memory beyond the intended buffer boundaries. Furthermore, from a threat modeling perspective using the MITRE ATT&CK framework for embedded systems, this flaw facilitates Denial of Service (T1499) by exhausting system resources or causing crashes through improper input validation in kernel-space modules. It also touches upon CWE-787, Out-of-bounds Write, if similar logic were applied to write operations, though the primary impact here is read-based instability leading to crash. The lack of proper bounds checking on user-supplied module names allows for exploitation by any module with sufficient privileges to invoke these object lookup functions.
Mitigation strategies must focus on enforcing strict boundary checks before initiating memory walks in privileged contexts. Developers should ensure that all length parameters provided by modules are validated against the actual size of the target memory region or a predefined maximum safe limit prior to execution. The deprecated function `txm_module_object_pointer_get` should be replaced with the extended version, which must then be patched to correctly use its length argument as an upper bound for iteration. Additionally, implementing runtime checks that verify preemption state before performing sensitive kernel operations can help detect such anomalies during development and testing phases. Regular code audits focusing on memory safety in module management components are essential to prevent similar issues where unchecked iterations lead to system instability or security breaches.