CVE-2026-95108
Deleting a user-mode module thread leaks its privileged kernel stack
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.
Attack profile
How easy it is to exploit
- Attack vector
- Local
- Complexity
- Low
- Privileges needed
- Low
- User interaction
- None
What an attacker can affect
- Confidentiality
- None
- Integrity
- None
- Availability
- High
Exploit likelihood
What each source reports
CVE List Score used
6.8
Deleting a user-mode module thread leaks its privileged kernel stack
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.
- Record
CVE-2026-95108- CVSS 4.0
- 6.8 Medium
CVSS:4.0/AV:L/AC:L/AT:N/PR:L/UI:N/VC:N/VI:N/VA:H/SC:N/SI:N/SA:N - Weakness
- CWE-400, CWE-772
- Updated
- 2026-11-02
EUVDEUVD-2026-105149
6.8
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.
- Record
EUVD-2026-105149- CVSS 4.0
- 6.8 Medium
CVSS:4.0/AV:L/AC:L/AT:N/PR:L/UI:N/VC:N/VI:N/VA:H/SC:N/SI:N/SA:N - Updated
- 2026-11-02
NVD
6.8
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.
- Record
CVE-2026-95108- CVSS 4.0
- 6.8 Medium
CVSS:4.0/AV:L/AC:L/AT:N/PR:L/UI:N/VC:N/VI:N/VA:H/SC:N/SI:N/SA:N/E:X/CR:X/IR:X/AR:X/MAV:X/MAC:X/MAT:X/MPR:X/MUI:X/MVC:X/MVI:X/MVA:X/MSC:X/MSI:X/MSA:X/S:X/AU:X/R:X/V:X/RE:X/U:X - Weakness
- CWE-400, CWE-772
- Updated
- 2026-11-02
OSV
6.8
Deleting a user-mode module thread leaks its privileged kernel stack
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.
- Record
CVE-2026-95108- CVSS 4.0
- 6.8 Medium
CVSS:4.0/AV:L/AC:L/AT:N/PR:L/UI:N/VC:N/VI:N/VA:H/SC:N/SI:N/SA:N - Weakness
- CWE-400, CWE-772
- Updated
- 2026-11-02
Affected products
History
| Recorded | Changed | Sources |
|---|---|---|
| first indexed | CVE List, EUVD, NVD, OSV |
Dates are when Every CVE recorded each change. Upstream dates may differ.
In short
CVE-2026-95108 is a medium vulnerability (CVSS 6.8) in Eclipse Foundation Threadx, published October 20, 2026. No source lists public exploit code. EPSS puts the chance of exploitation in the next 30 days at 0.17%, the 6th percentile. No source names a fixed version.