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`.
Analysis
Analysis and contextual insights are available on OpenCVE Cloud.
Default status is the baseline for the product, each version can override it (e.g. patched versions marked unaffected).
| Vendor | Product | Default status | Versions | |||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| Eclipse Foundation | Eclipse ThreadX | unaffected |
|
No data.
No data.
No data available yet.
No vendor fix or workaround currently provided.
Additional remediation guidance may be available on OpenCVE Cloud.
Tracking
Sign in to view the affected projects.
No advisories yet.
Tue, 20 Oct 2026 15:30:00 +0000
| Type | Values Removed | Values Added |
|---|---|---|
| Description | 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`. | |
| Title | Deleting a user-mode module thread leaks its privileged kernel stack | |
| Weaknesses | CWE-400 CWE-772 |
|
| References |
| |
| Metrics |
cvssV4_0
|
Subscriptions
No data.
MITRE
Status: PUBLISHED
Assigner: eclipse
Published:
Updated: 2026-10-20T15:19:16.940Z
Reserved: 2026-09-23T13:42:24.310Z
Link: CVE-2026-95108
Vulnrichment
No data.
NVD
Status : Received
Published: 2026-10-20T16:17:18.393
Modified: 2026-10-20T16:17:18.393
Link: CVE-2026-95108
Redhat
No data.
OpenCVE Enrichment
No data.