High severity · published Oct 20, 2026
CVE-2026-94192
Module object deallocation can free a live ThreadX kernel object
8.5
CVSS
0.1%
EPSS
No
On KEV
Description
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.
Exploitation
Is it being used?
Exploit prediction (EPSS)0.1% · higher than 4% of CVEs
Exploited in the wildNo evidence yet
CISA KEVNot listed
Ransomware campaign useNot known
Affected products
Which versions
ET
Eclipse ThreadX · Eclipse Foundation
6.0.1 through 6.5.1.202602a · source: vendor
Affected product
ET
Eclipse ThreadX
Eclipse Foundation
More from Eclipse ThreadX
8.5
CVE-2026-95109
Cortex-A7 module data validation checks only the first address of a caller-supplied range
7.0
CVE-2026-95107
Module object allocation size overflow corrupts the manager object pool
6.9
CVE-2026-94024
Module Manager object lookup validates one byte of a module's search name
6.9
CVE-2026-94023
Module delete dispatchers do not enforce kernel-object ownership before irreversible deletion
6.8
CVE-2026-95108
Deleting a user-mode module thread leaks its privileged kernel stack