CVE-2026-94192GHSA-57mf-w87f-rq7m
Module object deallocation can free a live ThreadX kernel object
Eclipse Foundation Eclipse ThreadX
CVSS
8.5HighExploitationNo known exploitationNot in CISA KEV, which does not prove it is unexploitedCISA KEV
Exploit odds (EPSS)0.15%Chance of exploitation activity in the next 30 days, higher than 3% of CVEs. Scored 23 Oct 2026FIRST EPSS
Fixed inNone listedNo source names a fixed version. Check the vendor advisory below
What fixes it
No source in this snapshot names a fixed version. The vendor advisories under References are the place to check.
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.
Text from CVE List
Affected versions 2
- Eclipse ThreadXaffected: 6.0.1 through 6.5.1.202602aCVE List
- Eclipse ThreadXunaffected: 6.5.2.202603CVE List