CVE-2026-95107
7.0HighPublished 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
- High impact on integrity, availability
- Weakness
- CWE-190, CWE-680, CWE-787
Impact
A local ThreadX module can corrupt kernel memory and crash the system or escalate integrity privileges. The attacker needs the ability to execute code as a module and invoke the object allocation API.
Root cause
An integer overflow occurs when `txm_module_object_allocate` adds a 16-byte private header to an unchecked `object_size`, causing an undersized pool allocation and an out-of-bounds heap write.
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:L/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
Upgrade Eclipse ThreadX to the patched release containing bounds checking in `txm_module_object_allocate`, or disallow untrusted ThreadX modules from calling the module manager object allocation API.
AI-suggested. Run it in staging first and check it against the vendor advisory. Why?
NVD 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.