CVE-2026-94192Module object deallocation can free a live ThreadX kernel object
Updated under an hour ago ()
Does this affect you?
It affects Eclipse Foundation Eclipse ThreadX. Add what you run to find out whether that includes you.
No exploitation reported and no EPSS estimate yet.
Do this next
Free account, 1 product
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.
- CVSS
- 8.5 HIGH (v4.0, CNA)CVSS:4.0/AV:L/AC:L/AT:N/PR:L/UI:N/VC:H/VI:H/VA:H/SC:N/SI:N/SA:N
- Weakness (CWE)
- CWE-416, CWE-664
- Known exploited
- Not in CISA's KEV catalog
- EPSS (exploitation in the next 30 days)
- Not loaded for this CVE
- Assigned by
- eclipse
- NVD analysis
- Awaiting Analysis
- Record last updated
- Oct 20, 2026
- First seen by InfoSec Signals
- Oct 20, 2026
Affected products
Eclipse Foundation Eclipse ThreadX eclipse_foundation:eclipse_threadx (from the name) | from 6.0.1 through 6.5.1.202602a; 6.5.2.202603 not affected | CNA record |
References
- https://github.com/eclipse-threadx/threadx/security/advisories/GHSA-57mf-w87f-rq7m
The CVE record on cve.org NVD's entry
The CVE record is authoritative. Products marked “from the name” were identified from the CNA's free-text names, not a CPE, and are matched less certainly. This product uses the NVD API but is not endorsed or certified by the NVD.