---
id: CVE-2026-94023
title: >-
  Module delete dispatchers do not enforce kernel-object ownership before
  irreversible deletion
summary: >-
  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*…
severity: medium
cvss: 6.9
cvssVector: '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'
cvssSource: cna
cwe:
  - CWE-125
  - CWE-862
vendor: Eclipse Foundation
product: ThreadX
affected:
  - ThreadX >= 6.0.1 <= 6.5.1.202602a
ssvc:
  exploitation: none
  automatable: 'no'
  technicalImpact: partial
  timestamp: '2026-10-20T17:03:38.985757Z'
published: '2026-10-20'
updated: '2026-10-20'
sourceUpdated: '2026-10-20T17:03:48.170Z'
source: CVEORG
sourceUrl: 'https://www.cve.org/CVERecord?id=CVE-2026-94023'
references:
  - url: >-
      https://github.com/eclipse-threadx/threadx/security/advisories/GHSA-36vf-7cx6-9f9j
tags:
  - cve.org
ingestedAt: '2026-10-20T16:10:53.318Z'
---

## Overview

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.

## Affected

- `ThreadX >= 6.0.1 <= 6.5.1.202602a`

## Remediation

Refer to the linked advisories for vendor-supplied fixes and affected version ranges.