---
id: "CVE-2026-94192"
kind: "vulnerability"
aliases: ["CVE-2026-94192"]
title: "ThreadX: module deallocation frees kernel objects still in use"
severity: "high"
cvss: 8.5
epss: null
exploited: false
status: "open"
category: "runtime"
products: []
ecosystems: []
tags: ["embedded", "rtos", "runtime", "threadx"]
not_affected_if: []
published_at: "2026-10-20T16:17:18+00:00"
first_seen_at: "2026-10-23T21:57:20+00:00"
updated_at: "2026-10-25T03:00:28+00:00"
sources: [{"source": "nvd", "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-94192", "first_seen_at": "2026-10-23T21:57:20+00:00"}]
---

# ThreadX: module deallocation frees kernel objects still in use

A ThreadX module can return kernel object control blocks to the Module Manager pool while the kernel still uses them, so the memory is reused by the next allocation. This is a use-after-free that can corrupt or hijack kernel object state.

_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-94192

## From the sources

A ThreadX module allocates the control blocks of its kernel objects from the Module Manager's object pool, and can ask for that memory back by address with `txm_module_object_deallocate`. The manager released it whatever was in it, including a control block the kernel was still using. Deallocation is not deletion: the object stays on the created list for its type, a thread stays wherever it was on the ready or suspension lists and stays schedulable, and an active timer stays on the timer list. The byte pool is meanwhile free to hand those same bytes to the next allocation.

---

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