Eclipse Threadx
Approved changes feed: RSS · Atom
cpe:2.3:a:eclipse_foundation:eclipse_threadx:*:*:*:*:*:*:*:*part: a version: * update: *
| Vendor | Eclipse Foundation (2c315c48-0111-5572-bbde-cc70cfafb2e9) |
|---|---|
| Product | Eclipse Threadx (85bbf722-7922-53d3-b513-73fb24b9e130) |
| Edition | * |
| Language | * |
| Software edition | * |
| Target software | * |
| Target hardware | * |
| Other | * |
Notes
Imported from gcve-enriched-dumps CVE data
PURL mappings
| PURL | Source | Last updated |
|---|---|---|
| No PURL mappings for this CPE yet. | ||
Vulnerability references
| Identifier | cpeApplicability | Submitted | db.gcve.eu details | Rationale |
|---|---|---|---|---|
CVE:CVE-2026-114408 |
vulnerable | 2026-11-04 14:59:33.806855 |
NULL pointer dereference in ICMPv6 Packet Too Big processing when the destination table is full
In Eclipse ThreadX NetX Duo versions 6.4.5.202504 through 6.5.2.202603a, built with IPv6 path MTU discovery, the ICMPv6 Packet Too Big handler uses the destination-table entry it adds without checking that the add succeeded. A sender on the network can fill the destination table with Packet Too Big messages quoting new destinations, after which the next message makes the IP helper thread dereference a NULL pointer, crashing it on targets that fault on address 0 and stopping all network processing.
Published: 2026-11-02T15:04:39.505Z
Updated: 2026-11-10T14:58:57.728Z |
Imported from gcve-enriched-dumps CVE data |
CVE:CVE-2026-95107 |
vulnerable | 2026-11-03 10:15:49.658650 |
Module object allocation size overflow corrupts the manager object pool
A ThreadX module chooses `object_size` when it calls `txm_module_object_allocate`. The Module Manager adds its own 16-byte private header to that size and asked the object pool for the result **without checking the addition**. A size near the top of a `ULONG` wrapped, the pool served a block far smaller than the header, and the manager then wrote the header past the end of it and into the neighbouring byte-pool block.
Published: 2026-10-20T15:20:15.011Z
Updated: 2026-10-20T17:05:35.811Z |
Imported from gcve-enriched-dumps CVE data |
CVE:CVE-2026-95108 |
vulnerable | 2026-11-03 10:15:49.575513 |
Deleting a user-mode module thread leaks its privileged kernel stack
One logical thread of a user-mode ThreadX module costs the Module Manager's shared object pool two allocations, not one. The module asks for a `TX_THREAD` control block through `txm_module_object_allocate`; `_txm_module_manager_thread_create` then takes a second allocation of `TXM_MODULE_KERNEL_STACK_SIZE` bytes for the privileged kernel stack that thread's system calls run on, and records it in the control block. Both come from `_txm_module_manager_object_pool` and both are linked onto the module's allocation list.
The Module Manager's thread-delete dispatcher released only the first. The kernel stack stayed allocated until the whole module was stopped, so a module that creates, terminates and deletes threads in a loop — every state transition valid, every service returning `TX_SUCCESS` — removed a fixed block from a finite pool shared by the manager and by every other loaded module, on every cycle, for as long as it stayed loaded. Once the pool is exhausted, no memory-protected module can create any kernel object and no user-mode module thread can be created anywhere in the system.
Vulnerable function: `_txm_module_manager_tx_thread_delete_dispatch`, in `common_modules/module_manager/inc/txm_module_manager_dispatch.h`.
Published: 2026-10-20T15:19:16.940Z
Updated: 2026-10-20T17:06:10.079Z |
Imported from gcve-enriched-dumps CVE data |
CVE:CVE-2026-95109 |
vulnerable | 2026-11-03 10:15:49.554719 |
Cortex-A7 module data validation checks only the first address of a caller-supplied range
The Cortex-A7 MMU Modules port validates a caller-supplied buffer by translating **one address** — the first byte. The common Module Manager hands its range check the module instance, the start address and the complete byte size; the Cortex-A7 implementation discarded the instance and the size and asked the MMU a single question about the start.
A memory-protected module therefore passed any range whose first byte was user-readable, however far the rest of it reached. Privileged dispatch code then read or wrote the whole range. Because every protected-module dispatcher that consumes a buffer or an extra-parameter array goes through this one macro, the defect is not in any individual service: it is in the primitive all of them rely on.
Published: 2026-10-20T15:17:20.023Z
Updated: 2026-10-20T17:07:15.973Z |
Imported from gcve-enriched-dumps CVE data |
CVE:CVE-2026-95111 |
vulnerable | 2026-11-03 10:15:49.528069 |
Module queue front-send validates a word count as a byte count
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.
Published: 2026-10-20T14:35:40.629Z
Updated: 2026-10-20T15:34:45.488Z |
Imported from gcve-enriched-dumps CVE data |
CVE:CVE-2026-94023 |
vulnerable | 2026-11-03 10:15:43.813283 | db.gcve.eu details were skipped to keep the page responsive. | Imported from gcve-enriched-dumps CVE data |
CVE:CVE-2026-94202 |
vulnerable | 2026-11-03 10:15:43.812314 | db.gcve.eu details were skipped to keep the page responsive. | Imported from gcve-enriched-dumps CVE data |
CVE:CVE-2026-94192 |
vulnerable | 2026-11-03 10:15:43.692205 | db.gcve.eu details were skipped to keep the page responsive. | Imported from gcve-enriched-dumps CVE data |
CVE:CVE-2026-94024 |
vulnerable | 2026-11-03 10:15:43.640422 | db.gcve.eu details were skipped to keep the page responsive. | Imported from gcve-enriched-dumps CVE data |
CVE:CVE-2026-0648 |
vulnerable | 2026-06-08 07:47:12.839217 | db.gcve.eu details were skipped to keep the page responsive. | Imported from gcve-enriched-dumps CVE data |
Contribute
You can submit an edit proposal for this CPE entry or suggest a related product/vendor addition using the action button above.
Inspect record JSON
Open this panel to browse, search, copy or download the JSON record.