CVE-2026-94192
8.5HighPublished 20 Oct 2026 · NVD status: Received · AI triage by gemini-3.8-flash
- Attack vector
- Local
- Complexity
- Low
- Privileges needed
- Low
- User interaction
- None
- Impact
- Full C/I/A compromise
- Weakness
- CWE-416, CWE-664
Impact
A local attacker with module-level access can cause memory corruption, execute arbitrary code, or crash the RTOS kernel. They trigger this by requesting deallocation of memory backing active kernel control blocks.
Root cause
`txm_module_object_deallocate` releases memory back to the byte pool without unlinking active control blocks from internal kernel queues like ready and timer lists, causing a use-after-free.
Affected systems
Versions not listed — check the vendor advisory.
CVSS v4.0 · 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/E:X/CR:X/IR:X/AR:X/MAV:X/MAC:X/MAT:X/MPR:X/MUI:X/MVC:X/MVI:X/MVA:X/MSC:X/MSI:X/MSA:X/S:X/AU:X/R:X/V:X/RE:X/U:X
Fix & remediation
Check the linked GitHub advisory (GHSA-57mf-w87f-rq7m) for patched versions of Eclipse ThreadX, rebuild firmware, and redeploy; prevent untrusted modules from invoking `txm_module_object_deallocate` on active object pools.
AI-suggested. Run it in staging first and check it against the vendor advisory. Why?
NVD 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.