Skip to content
fr Sign in
8.5 High

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.

Affected products and versions

Product Affected versions Fixed in
Eclipse ThreadX 6.5 earliest → < 6.5.2.202603 6.5.2.202603
Eclipse ThreadX 6.0 6.0.1 → 6.5.1.202602a No fix stated

References

Timeline

  1. Published
  2. Last modified

Other CVEs of Eclipse ThreadX

The 20 CVEs of 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 High 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 High CVE-2026-115215 In Eclipse ThreadX NetX Duo versions 6.0 through 6.5.2.202603a, the NetX Secure DTLS server allocates a session from its… 8.7 High CVE-2026-115403 In Eclipse ThreadX NetX Duo versions 6.0 through 6.5.2.202603a, built with BSD raw socket and IPv6 support, the IPv6 raw… 8.2 High
Track this CVE