CVE-2026-95107High· 7.0▾ TwilightA 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 nea…
▾ Twilight zone — High severity, or a signal on a lesser flaw
impact 38.5 · likelihood 0 · exploitation 0
Need a working PoC? Pro members can cast a request and our team develops one — it lands right here.
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.
ThreadX >= 6.0.1 <= 6.5.1.202602aRefer to the linked advisories for vendor-supplied fixes and affected version ranges.
Connected by shared product, vendor, weakness, or advisory.
CVE-2026-91189High· 7.1GUIX binary resource loader: unvalidated glyph range causes an integer underflow and a heap out-of-bounds write when loading an untrusted font or theme
CVE-2026-95109High· 8.5Cortex-A7 module data validation checks only the first address of a caller-supplied range
CVE-2026-102757High· 8.5An unprivileged, memory-protected ThreadX module can have the kernel read and write memory at addresses of its choosing, in privileged mode, and can use that to clear the MPU enable bit and remove its own isolation boundary. The Modul…
CVE-2026-93475Critical· 9.3Out-of-bounds Write via an Unbounded RSA Modulus in NetX Secure X.509
CVE-2026-94192High· 8.5Module object deallocation can free a live ThreadX kernel object
CVE-2026-94023Medium· 6.9Module delete dispatchers do not enforce kernel-object ownership before irreversible deletion