ThreadX Module Manager Deallocates Active Kernel Objects DoS
CVE-2026-94192 Published on October 20, 2026
Module object deallocation can free a live ThreadX kernel object
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.
Vulnerability Analysis
CVE-2026-94192 is exploitable with local system access, and requires small amount of user privileges. This vulnerability is considered to have a low attack complexity. The potential impact of an exploit of this vulnerability is considered to have no impact on confidentiality and integrity and availability.
Weakness Types
What is a Dangling pointer Vulnerability?
Referencing memory after it has been freed can cause a program to crash, use unexpected values, or execute code.
CVE-2026-94192 has been classified to as a Dangling pointer vulnerability or weakness.
Improper Control of a Resource Through its Lifetime
The software does not maintain or incorrectly maintains control over a resource throughout its lifetime of creation, use, and release.
Products Associated with CVE-2026-94192
Want to know whenever a new CVE is published for Eclipse Threadx? stack.watch will email you.
Affected Versions
Eclipse Foundation Eclipse ThreadX:- Version 6.0.1, <= 6.5.1.202602a is affected.
- Version 6.5.2.202603 is unaffected.