CVE-2026-95108 in ThreadX
Summary
by MITRE • 10/20/2026
One logical thread of a user-mode ThreadX module costs the Module Manager's shared object pool two allocations, not one. The module asks for a `TX_THREAD` control block through `txm_module_object_allocate`; `_txm_module_manager_thread_create` then takes a second allocation of `TXM_MODULE_KERNEL_STACK_SIZE` bytes for the privileged kernel stack that thread's system calls run on, and records it in the control block. Both come from `_txm_module_manager_object_pool` and both are linked onto the module's allocation list.
The Module Manager's thread-delete dispatcher released only the first. The kernel stack stayed allocated until the whole module was stopped, so a module that creates, terminates and deletes threads in a loop — every state transition valid, every service returning `TX_SUCCESS` — removed a fixed block from a finite pool shared by the manager and by every other loaded module, on every cycle, for as long as it stayed loaded. Once the pool is exhausted, no memory-protected module can create any kernel object and no user-mode module thread can be created anywhere in the system.
Vulnerable function: `_txm_module_manager_tx_thread_delete_dispatch`, in `common_modules/module_manager/inc/txm_module_manager_dispatch.h`.
If you want to get best quality of vulnerability data, you may have to visit VulDB.
Analysis
by VulDB Data Team • 10/20/2026
The vulnerability identified is a resource leak within the ThreadX Module Manager, specifically affecting the handling of thread deletion operations for user-mode modules. This issue stems from an asymmetry in memory allocation and deallocation logic during the lifecycle management of module threads. When a new thread is created via the `txm_module_object_allocate` function called by `_txm_module_manager_thread_create`, two distinct allocations are performed against the Module Manager's shared object pool, known as `_txm_module_manager_object_pool`. The first allocation secures the standard `TX_THREAD` control block required for basic thread management. The second allocation reserves a dedicated kernel stack of size `TXM_MODULE_KERNEL_STACK_SIZE` bytes. This privileged kernel stack is essential because it provides the execution context for system calls made by user-mode threads, ensuring they operate with appropriate privileges and isolation from other modules. Both allocations are tracked on the module's internal allocation list to facilitate cleanup upon module termination or thread deletion.
The critical flaw resides in the `_txm_module_manager_tx_thread_delete_dispatch` function located in `common_modules/module_manager/inc/txm_module_manager_dispatch.h`. This dispatcher is responsible for releasing resources when a specific thread within a user-mode module is terminated. However, it only releases the first allocation corresponding to the `TX_THREAD` control block. It fails to release the second allocation associated with the privileged kernel stack. Consequently, while the thread object itself becomes available for reuse or garbage collection by higher-level logic, the memory backing its kernel stack remains permanently allocated within `_txm_module_manager_object_pool`. This creates a classic resource leak scenario where resources are consumed but never returned to the pool during normal operational cycles of creating and destroying threads.
The operational impact of this vulnerability is severe due to the finite nature of the shared object pool. In scenarios where a module dynamically creates, terminates, and deletes threads in a loop—a pattern that is entirely valid according to ThreadX API specifications—each iteration consumes one additional block from the global memory pool without releasing it back. Since every state transition returns `TX_SUCCESS`, there are no error codes or exceptions to halt this process automatically. Over time, as long as the vulnerable module remains loaded in the system, these leaked kernel stack allocations accumulate. This gradual consumption of a fixed-size resource leads directly to pool exhaustion. Once `_txm_module_manager_object_pool` is depleted, the Module Manager can no longer satisfy allocation requests for any new kernel objects or user-mode threads across the entire embedded system.
This denial-of-service condition effectively paralyzes the multi-module architecture supported by ThreadX. No other loaded module will be able to create new threads or allocate necessary kernel objects because the shared pool is empty. This impacts not only the vulnerable module but also all other modules running on the same RTOS instance, leading to a system-wide failure of thread creation capabilities. The vulnerability exploits standard operational behaviors rather than requiring malicious input or complex exploitation techniques, making it particularly dangerous in long-running embedded systems where threads are frequently spawned and destroyed for task management purposes.
From a classification perspective, this flaw aligns with CWE-401, which describes the missing release of memory after effective use, leading to resource exhaustion. It also relates to CWE-772, specifically regarding the lack of releasing resources before exiting or terminating a process or thread component. In terms of attack vectors and tactics, while not directly exploitable for code execution in this context, it represents an availability impact consistent with Denial-of-Service (DoS) attacks found in MITRE ATT&CK frameworks under resource exhaustion techniques. The vulnerability highlights the importance of symmetric allocation and deallocation logic in kernel-level module managers where shared resources are critical to system stability.
Mitigation strategies must focus on correcting the deallocation logic within `_txm_module_manager_tx_thread_delete_dispatch`. Developers should ensure that when a thread is deleted, both the `TX_THREAD` control block and its associated privileged kernel stack allocation are released back into `_txm_module_manager_object_pool`. This may involve updating the dispatcher to iterate through the module's allocation list or maintaining explicit pointers in the thread control block for easy access during cleanup. Additionally, implementing robust monitoring of pool usage can help detect such leaks early in development cycles before they manifest as critical failures in production environments. Patching this issue requires careful review of all code paths that interact with `_txm_module_manager_object_pool` to ensure no other similar asymmetries exist within the Module Manager's lifecycle management functions.