Out-of-bounds Read and Unverified Entry Pointers in the ThreadX Module Loader
Default status is the baseline for the product, each version can override it (e.g. patched versions marked unaffected).
| Vendor | Product | Default status | Versions | |||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| Eclipse Foundation | Eclipse ThreadX | unaffected |
|
No data.
No data.
| Vendor | Product | Versions | ||||||||
|---|---|---|---|---|---|---|---|---|---|---|
| Eclipse | Threadx/threadx |
|
No CVSS v3.1
No CVSS v3.0
No CVSS v2
This CVE is not in the KEV list.
Exploit prediction score: < 1% (0.077% probability within 30 days)
| Type | Values Removed | Values Added |
|---|---|---|
| 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). | In Eclipse ThreadX versions 6.0.1 through 6.5.2.202603, the Module Manager loaders take a module image without its length and trust the sizes and offsets in its preamble. A crafted module image can declare a code size larger than the image to read, or gain access to, the memory that follows it, and can place its entry points outside its code. |
| Title | ThreadX Module Loader OOB Read and Unchecked Entry Point Vulnerabilities | Out-of-bounds Read and Unverified Entry Pointers in the ThreadX Module Loader |
| Metrics |
cvssV4_0
|
cvssV4_0
|
| Type | Values Removed | Values Added |
|---|---|---|
| First Time appeared |
Eclipse
Eclipse threadx/threadx |
|
| Vendors & Products |
Eclipse
Eclipse threadx/threadx |
| Type | Values Removed | Values Added |
|---|---|---|
| Title | ThreadX Module Loader OOB Read and Unchecked Entry Point Vulnerabilities |
| Type | Values Removed | Values Added |
|---|---|---|
| Metrics |
ssvc
|
| Type | Values Removed | Values Added |
|---|---|---|
| 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). | |
| Weaknesses | CWE-125 CWE-1284 CWE-345 |
|
| References |
| |
| Metrics |
cvssV4_0
|