6.9
Moyenne
CVE-2026-94023 A ThreadX module reaches a kernel object's delete service through the Module Manager's dispatch layer, which asked one…
Description
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* an object, and using an object a module does not own is supported and intended — `txm_module_object_pointer_get_extended` searches the system's created objects by name and hands back objects the application created and objects other modules created, so that a module can send to a shared queue, take a shared semaphore or get a shared mutex. Destroying one of those is not sharing it. A module could name any object it had a pointer to and have the privileged dispatcher delete it.
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