PT-2026-118439 · Eclipse Foundation · Eclipse Threadx

·

CVE-2026-94192

·

Published

2026-10-20

·

Updated

2026-10-20

CVSS v4.0

8.5

High

VectorAV:L/AC:L/AT:N/PR:L/UI:N/VC:H/VI:H/VA:H/SC:N/SI:N/SA:N
A ThreadX module allocates the control blocks of its kernel objects from the Module Manager's object pool, and can ask for that memory back by address with txm module object deallocate. The manager released it whatever was in it, including a control block the kernel was still using. Deallocation is not deletion: the object stays on the created list for its type, a thread stays wherever it was on the ready or suspension lists and stays schedulable, and an active timer stays on the timer list. The byte pool is meanwhile free to hand those same bytes to the next allocation.

Fix

Use After Free

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

Weakness Enumeration

Related Identifiers

CVE-2026-94192

Affected Products

Eclipse Threadx