The ThreadX loadable‑module loader processes modules received via _txm_module_manager_memory_load and _txm_module_manager_in_place_load without validating an image length field. Because the loader interprets the code_size field within the module preamble as the source-image length, it performs a heap out‑of‑bounds read during the code‑copy loop. Underscoring this defect is an unchecked control‑flow integrity gap: module entry, callback, and stop pointers are derived from the code_start plus an offset that is only checked for non‑zero, and the preamble checksum is never verified. Consequently, a maliciously crafted module can leak data from beyond the legitimate buffer and potentially manipulate control‑flow pointers to execute arbitrary code within the host process.

Eclipse Foundation ThreadX, specifically the module manager that loads user supplied modules via _txm_module_manager_memory_load and _txm_module_manager_in_place_load. The flaw applies to all versions of ThreadX that include the current implementation of the loadable‑module loader.

The risk assessment shows a CVSS score of 5.6, reflecting moderate seriousness, and the vulnerability is not yet listed in CISA KEV. While no EPSS value is available, the absence of an image length check indicates that exploitation would likely require local access to load a crafted module. Based on the description, it is inferred that an attacker able to supply modules could read data beyond the intended bounds and, if the control‑flow pointers are manipulated, might cause the host to execute injected code, potentially leading to local privilege escalation. No remote exploitation path is reported.