Live › vulnerability › CVE-2026-113421
ThreadX Modules does not clear a module's trace-buffer-full callback when the module is stopped and unloaded. A later trace buffer wrap can then call code that has already been released, running it with kernel privileges or redirecting control flow.
Summary written from the sources below. Check the originals before acting.
First seen by InfraStack 2026-11-03 09:19 UTC. All times on this page are UTC.
Systems built on Eclipse ThreadX 6.0.1 through 6.5.2.202603 that use ThreadX Modules with event tracing enabled and a kernel-owned trace buffer. Systems not using ThreadX Modules, or without event tracing, are likely not exposed; the sources do not state this explicitly.
No product ranges from the sources yet.
6.5.2.202603: the sources do not name the fixed version.Each row is the first time that source carried this signal. The analyst’s rows are its own findings.
In Eclipse ThreadX versions 6.0.1 through 6.5.2.202603, ThreadX Modules does not revoke a module's trace-buffer-full callback when the module is stopped and unloaded. With event tracing enabled and a kernel-owned trace buffer still active, a later buffer wrap invokes the callback from privileged thread context after the module's code has been released, so a user-mode module can have its code run with kernel privileges after unload, or, once the memory is reused, redirect control flow or cause a fault.
This page as .md · .json · in your agent: get_signal("CVE-2026-113421")
NVD data is provided by NIST and is public domain. Posts quoted belong to their authors.