CVE-2026-94192
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.
Published:Oct 20, 2026
Last Modified:Oct 20, 2026
EPS:Oct 20, 2026
EPSS Score:
CVSS Score:8.5
Affected Products
Vendor
Product
Action
Vendor
Eclipse
Product
Threadx
Eclipse
Threadx
Exploits
No exploit reference
Common Weakness Enumeration
Common Attack Pattern Enumeration and Classification (CAPEC)
Related CVEs
Common Vulnerability Scoring System
Attack Vector
Network
Adjacent
Local
Physical
Privileges Required
None
Low
High
User Interaction
None
Required
Scope
Unchanged
Changed
Confidentiality
None
Low
High
Integrity
None
Low
High
Availability
None
Low
High
