Two issues in the ThreadX loadable-module loader, reached when a device loads an attacker-controlled module object via `_txm_module_manager_memory_load` / `_txm_module_manager_in_place_load` — APIs th
What fixes it
No source in this snapshot names a fixed version. The vendor advisories under References are the place to check.
Description
Two issues in the ThreadX loadable-module loader, reached when a device loads an attacker-controlled module object via _txm_module_manager_memory_load / _txm_module_manager_in_place_load — APIs that take ONLY a base pointer, no image length, so every size/offset field in TXM_MODULE_PREAMBLE is fully attacker-trusted: (1) a heap OOB read (code_size trusted as the source-image length in the code-copy loop), and (2) a control-flow-integrity / defense-in-depth gap (module entry/start/callback/stop pointers computed as code_start + preamble_offset with only a != 0 check, and the preamble checksum never verified). No controlled OOB write was found (honest — the copy destination is overflow-guarded).
Text from CVE List
Affected versions 1
- `eclipse-threadx/threadx` (module manager / loadable-module loader)affected: current HEAD and prior (the `_txm_module_manager_*_load` APIs take no image length).CVE List