Live › vulnerability › CVE-2026-94023
Go to dashboardThreadX's Module Manager checks only whether an object lies outside a module's own memory before dispatching a delete call, so a module can destroy shared kernel objects such as queues, semaphores and mutexes that other modules or the application created. The sources do not describe a code-execution path, so the worst case is disruption of shared objects that other code depends on.
Summary written from the sources below. Check the originals before acting.
First seen by InfraStack 2026-10-23 21:57 UTC. All times on this page are UTC.
Systems built on ThreadX that load dynamic modules through the Module Manager, where more than one module or the application shares kernel objects by name. Systems without the Module Manager, or that load only trusted modules, are less exposed. The sources do not name affected versions.
No product ranges from the sources yet.
Each row is the first time that source carried this signal. The analyst’s rows are its own findings.
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.
This page as .md · .json · in your agent: get_signal("CVE-2026-94023")
NVD data is provided by NIST and is public domain. Posts quoted belong to their authors.