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.
Project Subscriptions
No data.
Advisories
No advisories yet.
Fixes
Solution
No solution given by the vendor.
Workaround
No workaround given by the vendor.
References
History
Tue, 20 Oct 2026 15:30:00 +0000
| Type | Values Removed | Values Added |
|---|---|---|
| Description | 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. | |
| Title | Module object allocation size overflow corrupts the manager object pool | |
| Weaknesses | CWE-190 CWE-680 CWE-787 |
|
| References |
| |
| Metrics |
cvssV4_0
|
Projects
Sign in to view the affected projects.
Status: PUBLISHED
Assigner: eclipse
Published:
Updated: 2026-10-20T15:20:15.011Z
Reserved: 2026-09-23T13:43:04.307Z
Link: CVE-2026-95107
No data.
Status : Received
Published: 2026-10-20T16:17:18.273
Modified: 2026-10-20T16:17:18.273
Link: CVE-2026-95107
No data.
OpenCVE Enrichment
No data.