Eclipse ThreadX CVE-2026-95108

Requires a system using the ThreadX Module Manager with memory-protected user-mode modules, and the attacker must be able to load or already execute such a module with the ability to call the thread create/terminate/delete services. The leak is triggered specifically by the thread-delete path (_txm_module_manager_tx_thread_delete_dispatch), which frees only the TX_THREAD control block and never the separately-allocated privileged kernel stack; the module must repeatedly cycle thread lifecycle and stay loaded for the shared pool to drain. Limiting factors: local access only (AV:L), low-but-nonzero privilege (PR:L - attacker-controlled module code), no remote or unauthenticated path, and impact limited to availability (denial of service). Systems not using user-mode/memory-protected modules are not exposed.

This is a resource-exhaustion denial-of-service (CWE-400) in the Eclipse ThreadX Module Manager, not a code-execution or data-disclosure flaw. The provided CVSS 4.0 vector (AV:L/AC:L/AT:N/PR:L/UI:N/VC:N/VI:N/VA:H) is internally consistent with the description: exploitation is local, requires low privileges (the attacker must already be running a loaded user-mode module), needs no user interaction, and impacts availability only (VC:N/VI:N). The 6.8 score is moderate and well-calibrated - there is no confidentiality or integrity impact, and no scope change. Real-world risk is bounded by the precondition: the attacker must already be able to load/execute a memory-protected user-mode module that can create and delete threads, so this is a privilege-bounded local DoS rather than a remote or unauthenticated threat. No EPSS score, KEV listing, or POC was provided; per the input there is no public exploit identified. The bug is deterministic and trivially triggered once an attacker controls a module (every service returns TX_SUCCESS while the kernel stack leaks), which raises reliability of exploitation, but the local/privileged gate keeps this a targeted insider/compromised-module concern rather than a broadly exploitable one. No signals conflict; the main missing data is EPSS and any independent confirmation of patched versions.

An attacker who can load or already controls a user-mode ThreadX module writes it to create, terminate, and delete a thread in a tight loop. Each iteration leaks one TXM_MODULE_KERNEL_STACK_SIZE block from the shared Module Manager object pool, and after enough cycles the pool is exhausted, after which no memory-protected module can create any kernel object and no user-mode module thread can be created system-wide. No public exploit code was identified at time of analysis, but the trigger is deterministic and requires only ordinary, successful ThreadX API calls.