Module object allocation size overflow corrupts the manager object pool
A ThreadX module chooses `object_size` when it calls `txm_module_object_allocate`. The Module Manager adds its own 16-byte private header to that size and asked the object pool for the result **without checking the addition**. A size near the top of a `ULONG` wrapped, the pool served a block far smaller than the header, and the manager then wrote the header past the end of it and into the neighbouring byte-pool block.
CVE-2026-95107
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-95107
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-95107
Source reference:
/cveMetadata/cveId
Publisher severity
high
Source reference: /containers/cna/metrics
- Event
- #42410 · Revision 1
- Added to Heist Feed
- Publisher date