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.
Analysis and contextual insights are available on OpenCVE Cloud.
No vendor fix or workaround currently provided.
Additional remediation guidance may be available on OpenCVE Cloud.
Tracking
Sign in to view the affected projects.
No advisories yet.
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
|
Subscriptions
No data.
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-20T18:45:13Z