Eclipse ThreadX CVE-2026-113421

Exploitation requires a specific build and deployment: ThreadX Modules in use, TX_ENABLE_EVENT_TRACE enabled with trace-buffer-full notification exposed to modules and the registered callback invoked directly on buffer wrap, a kernel-owned trace buffer that remains active after the module is unloaded, and released module code left in executable memory. The attacker must already be able to execute code inside a loaded user-mode module (PR:L) and must win a timing/sequencing condition (AT:P): the module unload must be followed by a trace-buffer wrap before the freed code allocation is overwritten or becomes inaccessible - conditions the module does not fully control. Limiting factors: the vector is local (AV:L, no remote/network path), the reported configuration is a user-mode MPU-protected GNU Cortex-M3 module with dynamically allocated module code (available from ThreadX 6.1.7), and whether the stale callback actually executes depends on the code-allocation and executable-memory configuration. Privileged modules are out of scope - they are trusted and not a security boundary.

Signals point to a genuine but conditional, non-urgent issue rather than a high-CVSS/low-real-risk false alarm. The CVSS v4.0 base is 7.3 (High) with AV:L/AC:L/AT:P/PR:L/UI:N - exploitation is LOCAL, requires the attacker to already have code execution inside a loaded user-mode module (PR:L), and carries AT:P because success depends on an attack timing/sequencing condition the module cannot fully control (unload must be followed by a trace-buffer wrap before the released code is overwritten or made inaccessible). Impact is high (VC:H/VI:H/VA:H) because a stale callback can run in privileged/kernel context, defeating module isolation. The vuln.today Decision label is 'this_week' (meaningful but not act_now/emergency). Exploitation status: no public exploit identified at time of analysis - the reporter observed post-unload privileged invocation in ten Cortex-M3 runs, but these have NOT been independently reproduced by the maintainers, and the reporter did NOT demonstrate code reuse, attacker-controlled payload, information disclosure, or a product-level exploit. No CISA KEV listing and no EPSS score are present in the input, so widespread-exploitation probability cannot be quantified - absence of EPSS/KEV is a data gap, not evidence of safety. Net: a real defense-in-depth/isolation-boundary bug that matters most to systems loading untrusted modules with event tracing enabled, but the local foothold requirement plus timing dependency make it a scheduled-remediation priority rather than a drop-everything emergency.

An attacker who can already run code inside an MPU-isolated user-mode ThreadX module (with TX_ENABLE_EVENT_TRACE built in) calls tx_trace_buffer_full_notify to register a trace-buffer-full callback, then arranges for the module to be stopped and unloaded while a kernel-owned trace buffer stays active. A later trace-buffer wrap from ordinary kernel activity invokes the now-stale callback in privileged thread context - either executing the unloaded module's retained code with kernel privileges or, if the freed allocation was reused, redirecting control flow or faulting. No public exploit code exists; the behavior was only observed by the reporter on Cortex-M3 and has not been independently reproduced by maintainers.