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).
https://github.com/eclipse-threadx/threadx/security/advisories/GHSA-f53h-37j4-mqxx
Published: 2026-09-29
Updated: 2026-09-29
Base Score: 7.5
Vector: CVSS2#AV:N/AC:L/Au:N/C:P/I:P/A:P
Severity: High
Base Score: 9.8
Vector: CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H
Severity: Critical
Base Score: 5.7
Vector: CVSS:4.0/AV:L/AC:H/AT:N/PR:N/UI:A/VC:H/VI:N/VA:L/SC:N/SI:N/SA:N
Severity: Medium
EPSS: 0.00075