CVE-2026-95108: CWE-400 Uncontrolled Resource Consumption in Eclipse Foundation Eclipse ThreadX
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`.
CVSS v4.0
Score 6.8medium
Affected software
Eclipse Foundation
Eclipse ThreadX
pkg:github/eclipse-threadx/threadxRun on your own infrastructure? Check whether these packages are installed with threat-finder — our free open-source scanner.
AI-Powered Analysis
Machine-generated threat intelligence
Technical Analysis
This vulnerability arises because each user-mode ThreadX thread consumes two allocations from the Module Manager's shared object pool: one for the TX_THREAD control block and one for the privileged kernel stack. While the thread-delete dispatcher releases the control block allocation, it fails to release the kernel stack allocation. Consequently, repeated creation and deletion of threads by a module depletes the shared pool, causing denial of service by preventing further kernel object or thread creation. The vulnerable function is _txm_module_manager_tx_thread_delete_dispatch in the module_manager_dispatch.h header.
Potential Impact
Exploitation of this vulnerability can lead to denial of service conditions where no new kernel objects or user-mode threads can be created system-wide due to exhaustion of the Module Manager's shared object pool. This impacts all memory-protected modules relying on this pool, potentially causing system instability or failure to perform thread-related operations.
Mitigation Recommendations
Patch status is not yet confirmed — check the vendor advisory for current remediation guidance. No official fix or patch links are provided in the available data. Until a patch is available, avoid workloads that create and delete user-mode threads in tight loops to reduce risk of exhausting the shared object pool.
Technical Details
- Data Version
- 5.2
- Assigner Short Name
- eclipse
- Date Reserved
- 2026-09-23T13:42:24.310Z
- Cvss Version
- 4.0
- State
- PUBLISHED
Threat ID: 6ad789f82cdf04f6563b84ac
Added to database: 10/20/2026, 15:34:16 UTC
Last enriched: 10/20/2026, 15:48:42 UTC
Last updated: 10/20/2026, 19:06:08 UTC
Views: 9
Community Reviews
0 reviewsCrowdsource mitigation strategies, share intel context, and vote on the most helpful responses. Sign in to add your voice and help keep defenders ahead.
Want to contribute mitigation steps or threat intel context? Sign in or create an account to join the community discussion.
Actions
Updates to AI analysis require Pro Console access. Upgrade inside Console → Billing.
External Links
Need more coverage?
Upgrade to Pro Console for AI refresh and higher limits.
For incident response and remediation, OffSeq services can help resolve threats faster.
Latest Threats
Check if your credentials are on the dark web
Instant breach scanning across billions of leaked records. Free tier available.