Live › vulnerability › CVE-2026-94192
Go to dashboardA ThreadX module can return kernel object control blocks to the Module Manager pool while the kernel still uses them, so the memory is reused by the next allocation. This is a use-after-free that can corrupt or hijack kernel object state.
Summary written from the sources below. Check the originals before acting.
First seen by InfraStack 2026-10-23 21:57 UTC. All times on this page are UTC.
No product ranges from the sources yet.
Each row is the first time that source carried this signal. The analyst’s rows are its own findings.
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.
This page as .md · .json · in your agent: get_signal("CVE-2026-94192")
NVD data is provided by NIST and is public domain. Posts quoted belong to their authors.