Eclipse ThreadX CVE-2026-94024

Exploitation requires that the target build uses the ThreadX Module Manager and loads modules whose trust is not guaranteed, and that the attacker can supply or compromise such a module so it invokes txm_module_object_pointer_get_extended (which is passed a length but never uses it to bound the buffer) or the deprecated txm_module_object_pointer_get (which supplies UINT max, removing the bound entirely) with a crafted object search name. Limiting factors: local vector only (AV:L) - no network reachability; PR:L - the attacker needs the privilege to load/run a module within the Module Manager, so a system that runs only vendor-trusted, statically-verified modules or that does not enable the Module Manager is not realistically exposed; no user interaction is required (UI:N) once a hostile module runs. The realistic outcome is a permanent scheduler hang (DoS), not privilege escalation or code execution.

The vendor-supplied CVSS 4.0 base score is 6.9 (Medium) with vector AV:L/AC:L/AT:N/PR:L/UI:N/VC:L/VI:N/VA:H/SC:N/SI:N/SA:N, and the primary impact is availability (VA:H): an attacker-controlled module forces an unbounded out-of-bounds read (CWE-125) in privileged kernel mode while the preemption count is raised, so a read fault permanently disables scheduling for the remaining uptime of the device - a durable, non-recoverable denial of service rather than code execution (VI:N) or meaningful data theft (VC:L only). The decisive limiting signal is PR:L combined with AV:L: this is NOT remotely reachable; the attacker must already be able to load and run a module within the Module Manager, so it is primarily a sandbox-escape-to-DoS (confidentiality of the module sandbox) rather than an internet-facing threat. No EPSS score, no CISA KEV listing, no SSVC decision data, and no POC indicator were provided in the input, so there is no public exploit identified at time of analysis and no evidence of active exploitation. Note a discrepancy to verify: the input Tags label this 'Buffer Overflow' and 'Information Disclosure', but the CWE (125, out-of-bounds read) and the description's own emphasis indicate the dominant real-world outcome is a permanent kernel hang (DoS), not a write-based overflow or a significant information leak - treat the tags as approximate, not as the actual impact profile. Overall this is a genuine but situational issue: high impact where loadable modules are used and partially untrusted, low urgency where the module set is fully trusted or the Module Manager is not deployed.

In a ThreadX deployment that uses the Module Manager to run partially-trusted loadable modules, a malicious or compromised module calls an object-pointer lookup dispatcher with a search name whose declared length is oversized (or, via the deprecated path, effectively unbounded). The kernel walks the name comparison past the module's buffer into memory a privileged read cannot access; the resulting fault occurs while preemption is disabled, hanging the scheduler for the rest of the system's life. No public exploit code is identified in the provided data, and the local attack vector (AV:L, PR:L) means the attacker must first be able to load/run a module.