Module object deallocation can free a live ThreadX kernel object
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.
CVE-2026-94192
Primary source · Revision 1
Imported from structured advisory data. Source references identify upstream records or fields; verify affected versions and your deployed configuration.
Security context
Source reference: cve:CVE-2026-94192
Eclipse ThreadX
Source reference: /containers/cna/affected/0/product
- Affected versions
- Not stated in this record
- Fixed versions
- Not stated in this record
- Prerequisites
- Not stated in this record
Structured affected-version data
Original package identities and version rules from this source.
[
{
"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"
}
]- Related CVEs
- CVE-2026-94192
Source reference:
/cveMetadata/cveId
Publisher severity
high
Source reference: /containers/cna/metrics
- Event
- #42408 · Revision 1
- Added to Heist Feed
- Publisher date