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.
No advisories yet.
Solution
No solution given by the vendor.
Workaround
No workaround given by the vendor.
Tue, 20 Oct 2026 21:00:00 +0000
| Type | Values Removed | Values Added |
|---|---|---|
| First Time appeared |
Eclipse
Eclipse threadx |
|
| Vendors & Products |
Eclipse
Eclipse threadx |
Tue, 20 Oct 2026 17:30:00 +0000
| Type | Values Removed | Values Added |
|---|---|---|
| Metrics |
ssvc
|
Tue, 20 Oct 2026 15:30:00 +0000
| Type | Values Removed | Values Added |
|---|---|---|
| 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. | |
| Title | Module delete dispatchers do not enforce kernel-object ownership before irreversible deletion | |
| Weaknesses | CWE-125 CWE-862 |
|
| References |
| |
| Metrics |
cvssV4_0
|
Projects
Sign in to view the affected projects.
Status: PUBLISHED
Assigner: eclipse
Published:
Updated: 2026-10-20T17:03:48.170Z
Reserved: 2026-09-23T13:43:04.333Z
Link: CVE-2026-94023
Updated: 2026-10-20T17:03:43.391Z
Status : Awaiting Analysis
Published: 2026-10-20T16:17:17.763
Modified: 2026-10-20T19:48:50.250
Link: CVE-2026-94023
No data.
OpenCVE Enrichment
Updated: 2026-10-20T20:30:30Z