CVE-2026-94192
HIGH
8,5
Source: [email protected]
Attack Vector: local
Attack Complexity: low
Privileges Required: low
User Interaction: none
Confidentiality: N/A
Integrity: N/A
Availability: N/A
Description
AI Translation Available
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.
416
Use After Free
StableCommon Consequences
Security Scopes Affected:
Integrity
Availability
Confidentiality
Potential Impacts:
Modify Memory
Dos: Crash, Exit, Or Restart
Read Memory
Execute Unauthorized Code Or Commands
Applicable Platforms
Languages:
Memory-Unsafe, C, C++
664
Improper Control of a Resource Through its Lifetime
DraftCommon Consequences
Security Scopes Affected:
Other
Potential Impacts:
Other
Applicable Platforms
All platforms may be affected
https://github.com/eclipse-threadx/threadx/security/advisories/GHSA-57mf-w87f-r…