ThreadX vulnerabilities
CVEs whose affected-version data names the ThreadX package. Each record lists the affected and patched versions; check a specific version with the dependency checker or POST /api/sbom.
13 CVEsRSS
CVE-2026-94192High· 8.5Module object deallocation can free a live ThreadX kernel object
A ThreadX module allocates the control blocks of its kernel objects from the Module Manager's object pool, and can ask for that memory back by address with `txm_module_object_deallocate`. The manager released it whatever was in it, inclu…
CVE-2026-94023Medium· 6.9Module delete dispatchers do not enforce kernel-object ownership before irreversible deletion
A ThreadX module reaches a kernel object's delete service through the Module Manager's dispatch layer, which asked one question about the pointer: does the object lie outside the module's own code and data. That is the policy for *using*…
CVE-2026-95109High· 8.5Cortex-A7 module data validation checks only the first address of a caller-supplied range
The Cortex-A7 MMU Modules port validates a caller-supplied buffer by translating **one address** — the first byte. The common Module Manager hands its range check the module instance, the start address and the complete byte size; the Cor…
CVE-2026-94024Medium· 6.9Module Manager object lookup validates one byte of a module's search name
The Module Manager's object lookup validated one byte of a memory-protected module's search name and then walked as much of it as the module declared, in privileged mode, with the kernel's preemption count raised. Both lookup dispatchers…
CVE-2026-95108Medium· 6.8Deleting a user-mode module thread leaks its privileged kernel stack
One logical thread of a user-mode ThreadX module costs the Module Manager's shared object pool two allocations, not one. The module asks for a `TX_THREAD` control block through `txm_module_object_allocate`; `_txm_module_manager_thread_cr…
CVE-2026-95107High· 7.0Module 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 nea…
CVE-2026-94202Medium· 4.8Module block-pool create validates two of the four parameter words it reads
The Module Manager's block-pool create dispatcher proved that two `ALIGN_TYPE` words of the extra-parameter array a memory-protected module supplies lay inside the module's data, and then used indices 0 through 3 of that array. One of…
CVE-2026-95111Medium· 4.8Module queue front-send validates a word count as a byte count
A memory-protected ThreadX module's queue request reaches the Module Manager's dispatch layer, which decides how much of the module's buffer the privileged queue copy may touch and hands that extent to the module port's range check. A qu…
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…
An 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-102709High· 8.4Improper validation of non-secure (NS) pointers in multiple TrustZone-M non-secure callable (NSC) entry functions allows an attacker executing in the non-secure world to supply pointers to secure memory
Improper validation of non-secure (NS) pointers in multiple TrustZone-M non-secure callable (NSC) entry functions allows an attacker executing in the non-secure world to supply pointers to secure memory. The secure firmware subsequently …
CVE-2025-55080High· 7.1In Eclipse ThreadX before 6.4.3, when memory protection is enabled, syscall parameters verification wasn't enough, allowing an attacker to obtain an arbitrary memory read/write.
In Eclipse ThreadX before 6.4.3, when memory protection is enabled, syscall parameters verification wasn't enough, allowing an attacker to obtain an arbitrary memory read/write.
CVE-2025-55079Medium· 5.5In Eclipse ThreadX before version 6.4.3, the thread module has a setting of maximum priority
In Eclipse ThreadX before version 6.4.3, the thread module has a setting of maximum priority. In some cases the check of that maximum priority wasn't performed, allowing, as a result, to obtain a thread with higher priority than expected…
CVE-2025-55078Medium· 5.5In Eclipse ThreadX before version 6.4.3, an attacker can cause a denial of service (crash) by providing a pointer to a reserved or unmapped memory region
In Eclipse ThreadX before version 6.4.3, an attacker can cause a denial of service (crash) by providing a pointer to a reserved or unmapped memory region. Vulnerable system calls had a check of pointers, but that check wasn't verifying w…