---
id: "CVE-2026-95108"
kind: "vulnerability"
aliases: ["CVE-2026-95108"]
title: "ThreadX: deleting a user-mode thread leaks its kernel stack, exhausting the pool"
severity: "medium"
cvss: 6.8
epss: null
exploited: false
status: "open"
category: "runtime"
products: []
ecosystems: []
tags: ["embedded", "rtos", "runtime", "threadx"]
not_affected_if: ["no-user-mode-modules"]
published_at: "2026-10-20T16:17:18+00:00"
first_seen_at: "2026-10-23T21:57:20+00:00"
updated_at: "2026-10-25T03:44:39+00:00"
sources: [{"source": "nvd", "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-95108", "first_seen_at": "2026-10-23T21:57:20+00:00"}]
---

# ThreadX: deleting a user-mode thread leaks its kernel stack, exhausting the pool

In the ThreadX Module Manager, deleting a user-mode thread frees only its control block and not the privileged kernel stack allocated with it. A module that repeatedly creates and deletes threads drains a finite shared object pool, so later module thread or object creation fails for the whole system (denial of service).

_Summary, check and fix written by a model from the sources; labelled as such._

## How to check

- unknown

## Fix

- unknown

## Timeline

- 2026-10-23T21:57:20+00:00 nvd https://nvd.nist.gov/vuln/detail/CVE-2026-95108

## From the sources

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`.

---

_Free to read at a human pace. An API with keys and an MCP server are in preparation; early access: hello@infrastack.ai_