Live › vulnerability › CVE-2026-95107
Go to dashboardThe ThreadX Module Manager adds a 16-byte header to a caller-chosen object size without checking for integer overflow. A size near the top of a ULONG wraps around, so the pool hands out a block too small for the header and the header write spills into neighbouring memory.
Summary written from the sources below. Check the originals before acting.
First seen by InfraStack 2026-10-23 21:57 UTC. All times on this page are UTC.
Teams that build ThreadX applications using the Module Manager, where a module can call txm_module_object_allocate with a caller-controlled object_size. Systems that do not use the ThreadX Module Manager are not affected by this specific flaw. The sources do not say which configurations or versions are exposed.
No product ranges from the sources yet.
txm_module_object_allocate in the build)Each row is the first time that source carried this signal. The analyst’s rows are its own findings.
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.
This page as .md · .json · in your agent: get_signal("CVE-2026-95107")
NVD data is provided by NIST and is public domain. Posts quoted belong to their authors.