PT-2026-118437 · Eclipse Foundation · Eclipse Threadx

·

CVE-2026-94023

·

Published

2026-10-20

·

Updated

2026-10-20

CVSS v4.0

6.9

Medium

VectorAV:L/AC:L/AT:N/PR:L/UI:N/VC:N/VI:H/VA:H/SC:N/SI:N/SA:N/E:X/CR:X/IR:X/AR:X/MAV:X/MAC:X/MAT:X/MPR:X/MUI:X/MVC:X/MVI:X/MVA:X/MSC:X/MSI:X/MSA:X/S:X/AU:X/R:X/V:X/RE:X/U:X
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.

Fix

Missing Authorization

Out of bounds Read

Found an issue in the description? Have something to add? Feel free to write us 👾

Weakness Enumeration

Related Identifiers

CVE-2026-94023

Affected Products

Eclipse Threadx