Module queue front-send validates a word count as a byte count
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 |
|
No CVSS v3.1
No CVSS v3.0
No CVSS v2
This CVE is not in the KEV list.
Exploit prediction score: < 1% (0.141% probability within 30 days)
| Type | Values Removed | Values Added |
|---|---|---|
| First Time appeared |
Eclipse
Eclipse threadx |
|
| Vendors & Products |
Eclipse
Eclipse threadx |
| Type | Values Removed | Values Added |
|---|---|---|
| Metrics |
ssvc
|
| Type | Values Removed | Values Added |
|---|---|---|
| Description | A memory-protected ThreadX module's queue request reaches the Module Manager's dispatch layer, which decides how much of the module's buffer the privileged queue copy may touch and hands that extent to the module port's range check. A queue's `tx_queue_message_size` is a count of `ULONG`s and the copy moves that many words, so the extent is `message_size * sizeof(ULONG)` bytes. The front-send dispatcher passed the word count itself. `tx_queue_send` and `tx_queue_receive`, either side of it in the same header, have always multiplied. A source buffer ending `message_size` bytes into memory the module may read was therefore accepted, and `_txe_queue_front_send` then read `message_size * sizeof(ULONG)` bytes from it in privileged mode — `3 * message_size` bytes past the end of what the module is allowed to read. The words are written into the queue's message area, so a module that can receive from that queue reads them back. | |
| Title | Module queue front-send validates a word count as a byte count | |
| Weaknesses | CWE-125 CWE-131 |
|
| References |
| |
| Metrics |
cvssV4_0
|