Approved changes feed: RSS · Atom

cpe:2.3:a:eclipse_foundation:eclipse_threadx:*:*:*:*:*:*:*:*

part: a version: * update: *

VendorEclipse Foundation (2c315c48-0111-5572-bbde-cc70cfafb2e9)
ProductEclipse 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

PURLSourceLast updated
No PURL mappings for this CPE yet.

Vulnerability references

IdentifiercpeApplicabilitySubmitteddb.gcve.eu detailsRationale
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
Reference links
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
Reference links
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
Reference links
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
Reference links
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
Reference links
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 JSON directly

Open this panel to browse, search, copy or download the JSON record.