Answer in brief
CVE-2026-94023 records a Medium severity (CVSS 6.9) vulnerability in Module delete dispatchers do not enforce kernel-object ownership before irreversible deletion. The current sources do not mark it as known exploited. The current feed maps Eclipse Foundation/Eclipse ThreadX (generic). Check affected ranges and fixed versions before updating.
Analysis pending evidence review
HOL Guard separates source facts from reviewed analysis. See the methodology.
CVSS is 6.9. The current sources do not mark it as known exploited. Treat this as a source-backed prioritization signal, not a statement about your environment.
Analysis status
Analysis pending evidence review
Factual feed record only; HOL analysis is not approved for indexing. Read the methodology.
The current feed maps Eclipse Foundation/Eclipse ThreadX (generic). Check affected ranges and fixed versions before updating.
| Package | Affected range | Fixed version |
|---|---|---|
| Eclipse Foundation/Eclipse ThreadXgeneric | >=6.0.1 <=6.5.1.202602a | Not reported |
Published upstream
Oct 20, 2026
Evidence: source:cvelist:source_dates:source-dates:recordSource modified
Oct 20, 2026
Evidence: source:cvelist:source_dates:source-dates:recordFirst seen by HOL
Oct 20, 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.
Quoted source text, attributed separately from HOL analysis.