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.

CVSS

No CVSS.

References

Link	Resource
https://github.com/eclipse-threadx/threadx/security/advisories/GHSA-57mf-w87f-rq7m

Configurations

No configuration.

History

20 Oct 2026, 16:17

Type	Values Removed	Values Added
New CVE

Information

Published : 2026-10-20 16:17

Updated : 2026-10-20 19:48

NVD link : CVE-2026-94192

Mitre link : CVE-2026-94192

CVE.ORG link : CVE-2026-94192

JSON object : View

Products Affected

No product.

CWE

CWE-416

Use After Free

CWE-664

Improper Control of a Resource Through its Lifetime

{"id": "CVE-2026-94192", "cveTags": [], "metrics": {"ssvcV203": [{"source": "134c704f-9b21-4f2e-91b3-4a467353bcc0", "ssvcData": {"id": "CVE-2026-94192", "role": "CISA Coordinator", "options": [{"exploitation": "none"}, {"automatable": "no"}, {"technicalImpact": "total"}], "version": "2.0.3", "timestamp": "2026-10-20T17:04:14.458746Z"}}], "cvssMetricV40": [{"type": "Secondary", "source": "emo@eclipse.org", "cvssData": {"Safety": "NOT_DEFINED", "version": "4.0", "Recovery": "NOT_DEFINED", "baseScore": 8.5, "Automatable": "NOT_DEFINED", "attackVector": "LOCAL", "baseSeverity": "HIGH", "valueDensity": "NOT_DEFINED", "vectorString": "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", "exploitMaturity": "NOT_DEFINED", "providerUrgency": "NOT_DEFINED", "userInteraction": "NONE", "attackComplexity": "LOW", "attackRequirements": "NONE", "privilegesRequired": "LOW", "subIntegrityImpact": "NONE", "vulnIntegrityImpact": "HIGH", "integrityRequirement": "NOT_DEFINED", "modifiedAttackVector": "NOT_DEFINED", "subAvailabilityImpact": "NONE", "vulnAvailabilityImpact": "HIGH", "availabilityRequirement": "NOT_DEFINED", "modifiedUserInteraction": "NOT_DEFINED", "modifiedAttackComplexity": "NOT_DEFINED", "subConfidentialityImpact": "NONE", "vulnConfidentialityImpact": "HIGH", "confidentialityRequirement": "NOT_DEFINED", "modifiedAttackRequirements": "NOT_DEFINED", "modifiedPrivilegesRequired": "NOT_DEFINED", "modifiedSubIntegrityImpact": "NOT_DEFINED", "modifiedVulnIntegrityImpact": "NOT_DEFINED", "vulnerabilityResponseEffort": "NOT_DEFINED", "modifiedSubAvailabilityImpact": "NOT_DEFINED", "modifiedVulnAvailabilityImpact": "NOT_DEFINED", "modifiedSubConfidentialityImpact": "NOT_DEFINED", "modifiedVulnConfidentialityImpact": "NOT_DEFINED"}}]}, "affected": [{"source": "emo@eclipse.org", "affectedData": [{"vendor": "Eclipse Foundation", "product": "Eclipse ThreadX", "versions": [{"status": "affected", "version": "6.0.1", "versionType": "semver", "lessThanOrEqual": "6.5.1.202602a"}, {"status": "unaffected", "version": "6.5.2.202603"}], "packageName": "ThreadX", "defaultStatus": "unaffected"}]}], "published": "2026-10-20T16:17:18.030", "references": [{"url": "https://github.com/eclipse-threadx/threadx/security/advisories/GHSA-57mf-w87f-rq7m", "source": "emo@eclipse.org"}], "vulnStatus": "Awaiting Analysis", "weaknesses": [{"type": "Secondary", "source": "emo@eclipse.org", "description": [{"lang": "en", "value": "CWE-416"}, {"lang": "en", "value": "CWE-664"}]}], "descriptions": [{"lang": "en", "value": "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."}], "lastModified": "2026-10-20T19:48:50.250", "sourceIdentifier": "emo@eclipse.org"}