CVE-2026-94192

high

Description

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.

References

https://github.com/eclipse-threadx/threadx/security/advisories/GHSA-57mf-w87f-rq7m

https://euvd.enisa.europa.eu/vulnerability/EUVD-2026-105144

Details

Source: Mitre, NVD

Published: 2026-10-20

Updated: 2026-10-20

Risk Information

CVSS v2

Base Score: 6.4

Vector: CVSS2#AV:N/AC:L/Au:N/C:P/I:N/A:P

Severity: Medium

CVSS v3

Base Score: 6.5

Vector: CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H

Severity: Medium

CVSS v4

Base Score: 8.5

Vector: CVSS:4.0/AV:L/AC:L/AT:N/PR:L/UI:N/VC:H/VI:H/VA:H/SC:N/SI:N/SA:N

Severity: High

EPSS

EPSS: 0.00147