CVE-2026-94023 PUBLISHED

Module delete dispatchers do not enforce kernel-object ownership before irreversible deletion

Assigner: eclipse
Reserved: 23.09.2026 Published: 20.10.2026 Updated: 20.10.2026

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.

Metrics

CVSS Vector: CVSS:4.0/AV:L/AC:L/AT:N/PR:L/UI:N/VC:N/VI:H/VA:H/SC:N/SI:N/SA:N
CVSS Score: 6.9

Product Status

Vendor Eclipse Foundation
Product Eclipse ThreadX
Versions Default: unaffected
  • affected from 6.0.1 to 6.5.1.202602a (incl.)
  • Version 6.5.2.202603 is unaffected

Credits

  • fdesbiens finder

References

Problem Types

  • CWE-125 Out-of-bounds Read CWE
  • CWE-862 Missing Authorization CWE