8.5
Élevée
CVE-2026-94192 A ThreadX module allocates the control blocks of its kernel objects from the Module Manager's object pool, and can ask…
Description
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, including a control block the kernel was still using. Deallocation is not deletion: the object stays on the created list for its type, a thread stays wherever it was on the ready or suspension lists and stays schedulable, and an active timer stays on the timer list. The byte pool is meanwhile free to hand those same bytes to the next allocation.
Produits et versions touchés
| Produit | Versions touchées | Corrigé en |
|---|---|---|
| Eclipse ThreadX 6.5 | premières → < 6.5.2.202603 | 6.5.2.202603 |
| Eclipse ThreadX 6.0 | 6.0.1 → 6.5.1.202602a | Pas de correctif indiqué |
Autres CVE de Eclipse ThreadX
Les 20 CVE de Eclipse ThreadX →
CVE-2026-113421
In Eclipse ThreadX versions 6.0.1 through 6.5.2.202603, ThreadX Modules does not revoke a module's trace-buffer-full…
7.3
Élevée
CVE-2026-115231
In Eclipse ThreadX versions 6.0.1 through 6.5.2.202603, the Module Manager lets a user-mode, memory-protected module…
8.5
Élevée
CVE-2026-115215
NetX Secure DTLS server allocates a session for each new source before the cookie exchange and never reclaims it, so spoofed datagrams exhaust the session pool
8.7
Élevée
CVE-2026-115403
NULL pointer dereference in the BSD raw IPv6 send path when the destination table is full
8.2
Élevée