Eclipse Threadx
Don't miss out!
Thousands of developers use stack.watch to stay informed.Get an email whenever new security vulnerabilities are reported in Eclipse Threadx.
By the Year
In 2026 there have been 21 vulnerabilities in Eclipse Threadx with an average score of 6.5 out of ten. Last year, in 2025 Threadx had 3 security vulnerabilities published. That is, 18 more vulnerabilities have already been reported in 2026 as compared to last year.
| Year | Vulnerabilities | Average Score |
|---|---|---|
| 2026 | 21 | 6.46 |
| 2025 | 3 | 0.00 |
| 2024 | 2 | 7.80 |
It may take a day or so for new Threadx vulnerabilities to show up in the stats or in the list of recent security vulnerabilities. Additionally vulnerabilities may be tagged under a different product or component name.
Recent Eclipse Threadx Security Vulnerabilities
ThreadX Module Manager Buffer Overwrite via Object Size Miscalc
CVE-2026-95107
7 - High
- October 20, 2026
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.
Integer Overflow or Wraparound
ThreadX Module Manager OOB Read in Block-Pool Dispatcher
CVE-2026-94202
4.8 - Medium
- October 20, 2026
The Module Manager's block-pool create dispatcher proved that two `ALIGN_TYPE` words of the extra-parameter array a memory-protected module supplies lay inside the module's data, and then used indices 0 through 3 of that array. One of the two unproved words is read by the dispatcher's own buffer check, which takes index 1 as the pool start and index 2 as the length to range-check it over. So the out-of-bounds read is performed by the validation code itself, before the kernel service is reached, and the size the caller's pool start is then validated against is a word the manager has not proved the module owns. The other unproved word is read when the service's argument list is built. Vulnerable function: `_txm_module_manager_tx_block_pool_create_dispatch`, in `common_modules/module_manager/inc/txm_module_manager_dispatch.h`.
Out-of-bounds Read
ThreadX ModuleMgr memory leak via _txm_module_manager_tx_thread_delete_dispatch
CVE-2026-95108
6.8 - Medium
- October 20, 2026
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`.
Resource Exhaustion
ThreadX Module Manager Buffer Overflow in Privileged Mode
CVE-2026-94024
6.9 - Medium
- October 20, 2026
The Module Manager's object lookup validated one byte of a memory-protected module's search name and then walked as much of it as the module declared, in privileged mode, with the kernel's preemption count raised. Both lookup dispatchers are affected: the recommended `txm_module_object_pointer_get_extended` is handed a length and does not use it to bound the buffer, and the deprecated `txm_module_object_pointer_get` supplies the largest value a `UINT` can hold, so it removes the bound rather than lacking one. A module can make the walk unbounded without knowing anything about the memory it reaches, and where the walk reaches memory a privileged read cannot take, the resulting fault leaves the kernel unable to preempt for the rest of the system's life. Vulnerable functions: `_txm_module_manager_txm_module_object_pointer_get_dispatch`, `_txm_module_manager_txm_module_object_pointer_get_extended_dispatch` (both in `common_modules/module_manager/inc/txm_module_manager_dispatch.h`) and `_txm_module_manager_object_name_compare` (`common_modules/module_manager/src/txm_module_manager_util.c`).
Out-of-bounds Read
ThreadX Module Manager Delete Service Privilege Escalation
CVE-2026-94023
6.9 - Medium
- October 20, 2026
A ThreadX module reaches a kernel object's delete service through the Module Manager's dispatch layer, which asked one question about the pointer: does the object lie outside the module's own code and data. That is the policy for *using* an object, and using an object a module does not own is supported and intended `txm_module_object_pointer_get_extended` searches the system's created objects by name and hands back objects the application created and objects other modules created, so that a module can send to a shared queue, take a shared semaphore or get a shared mutex. Destroying one of those is not sharing it. A module could name any object it had a pointer to and have the privileged dispatcher delete it.
Out-of-bounds Read
ARM Cortex-A7 MMU Buffer Validation Flaw (CVE-2026-95109)
CVE-2026-95109
8.5 - High
- October 20, 2026
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.
Out-of-bounds Read
ThreadX Module Manager Deallocates Active Kernel Objects DoS
CVE-2026-94192
8.5 - High
- October 20, 2026
A ThreadX module allocates the control blocks of its kernel objects from the Module Manager's object pool, and can ask for that memory back by address with `txm_module_object_deallocate`. The manager released it whatever was in it, including a control block the kernel was still using. Deallocation is not deletion: the object stays on the created list for its type, a thread stays wherever it was on the ready or suspension lists and stays schedulable, and an active timer stays on the timer list. The byte pool is meanwhile free to hand those same bytes to the next allocation.
Dangling pointer
Overread in GEF MultiLine TextView
CVE-2026-91057
4.6 - Medium
- October 20, 2026
`_gx_multi_line_text_view_display_info_get()` reads one byte past the end of the application's text buffer when the string it is given ends with a carriage return (`\r`). The over-read can also cause callers to advance their index past the end of the string, producing a second over-read in `_gx_multi_line_text_view_string_total_rows_compute()` and a row of text that is not in the source.
Out-of-bounds Read
Buffer Overread + Infinite Loop in GUIX JPEG Decoder (GX_SOFTWARE_DECODER_SUPPORT)
CVE-2026-92454
6.1 - Medium
- October 20, 2026
The GUIX software JPEG decoder reads four kinds of marker segment without checking that each is long enough to hold what it reads. A truncated segment is therefore read past the end of the caller's image buffer. Separately, a zero chroma sampling factor makes the block decode loop non-terminating. Both reproduce in the default configuration, in which `GX_SOFTWARE_DECODER_SUPPORT` is enabled.
Out-of-bounds Read
GUIX JPEG Decoder Buffer Overread via SOF0 After SOS
CVE-2026-91059
6.8 - Medium
- October 20, 2026
The GUIX JPEG software decoder enforces no ordering on JPEG markers. A file that places a second `SOF0` frame header after `SOS` re-runs the frame header parser after the output buffer has already been allocated and its geometry latched. The decoder returns `GX_SUCCESS` and publishes a `GX_PIXELMAP` whose reported dimensions and `data_size` exceed the allocation behind it. Any consumer that trusts the returned structure reads out of bounds, including GUIX's own display drivers, reached through the ordinary draw path. Reproduces in the shipped default configuration; `GX_SOFTWARE_DECODER_SUPPORT` is enabled by default.
Out-of-bounds Read
GuiX binary loader buffer overflow via malformed glyph range
CVE-2026-91189
7.1 - High
- October 20, 2026
The GUIX binary resource loader never checks that a font page's glyph range is well formed. `gx_page_header_first_glyph` and `gx_page_header_last_glyph` are read verbatim from the file and only the upper bound of `last_glyph` is validated, so a page declaring `first_glyph > last_glyph` makes `last - first + 1` underflow to a very large unsigned count. That count is multiplied by a glyph record size to reserve the load buffer, and the multiply is unchecked, so it wraps to a small value and the loader allocates a buffer far smaller than the data it is about to write. The load pass then recomputes the count in a narrower type and writes attacker-controlled glyph records into the undersized buffer.
Integer Overflow or Wraparound
Buffer Overread in GX Binres Loader (gx_binres_* functions)
CVE-2026-92446
6.8 - Medium
- October 20, 2026
`gx_binres_theme_load()` and `gx_binres_font_load()` take the resource as a bare `GX_UBYTE *` with no length, and `GX_BINRES_DATA_INFO` has no field to carry one. Every read is therefore performed at an offset the file itself chose, against a buffer whose extent the loader does not know. A resource that declares more data than it contains is read past its end, and an offset stored in the file is turned into a pointer without being bounded. This is a distinct defect from GHSA-hgcj-22cg-4hfv, which was an underflowed glyph count. It needs no underflow and no wrapped multiply: a perfectly well-formed, narrow glyph range reaches it.
Out-of-bounds Read
GUIX _gx_binres_pixelmap_table_load BOF in Theme Loader: 256KB overflow
CVE-2026-92449
6.8 - Medium
- October 20, 2026
`_gx_binres_pixelmap_table_load()` in the GUIX binary resource (theme) loader indexes the pixelmap table with a value read verbatim from the resource file and never bounds it against the table size. A crafted theme drives a write of up to roughly 256 KB past the end of the table. The overflowed buffer is allocated by GUIX itself, through `_gx_system_memory_allocator`, rather than supplied by the caller, so the loader corrupts its own arena. The public API `gx_binres_theme_load()` takes no size parameter, so no amount of caller diligence prevents this. Reproduces in the shipped default configuration; `GX_BINARY_RESOURCE_SUPPORT` is enabled by default.
out-of-bounds array index
Eclipse GUIX PNG reader memory overrun via duplicated IHDR chunk
CVE-2026-91186
8.4 - High
- October 20, 2026
The PNG chunk reader has no notion of chunk ordering. It records whether an IDAT has been seen and whether a tRNS has already supplied transparency, but nothing prevents an IHDR being read a second time. A PNG carries exactly one IHDR and it is the first chunk. A file that places a second one after IDAT rewrites the image width, height, bit depth and pixel depth *after* the decoded-data buffer has already been allocated and filled from the original values. The pass that reverses the PNG row filters then derives its own extent from the new dimensions and walks the old allocation, moving image bytes past the end of it. The buffer is allocated by GUIX rather than supplied by the caller, so the application has no way to size it defensively. The decoder is compiled in by default.
Out-of-bounds Read
ThreadX Queue Copy OOB Read Vulnerability
CVE-2026-95111
4.8 - Medium
- October 20, 2026
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.
Out-of-bounds Read
USBX Heap Buffer Overread via Malicious MTP/PTP Device
CVE-2026-96402
5.2 - Medium
- October 20, 2026
A malicious USB MTP/PTP device can cause the USBX host to read past a heap buffer during ordinary object enumeration, leaking adjacent heap contents to the application or faulting on an unmapped page.
Out-of-bounds Read
USBX Host Descriptors Overrun via VideoStreaming Descriptor Mismatch
CVE-2026-96406
4.9 - Medium
- October 20, 2026
A VideoStreaming interface reports the size of its whole class-specific descriptor block in the `wTotalLength` field of its input header. The USBX host recorded that figure and used it as the budget for walking the format, frame and frame-interval descriptors, without holding it against the configuration descriptor actually received. A device that reports a `wTotalLength` larger than the descriptors it supplies therefore had its own claim believed. Once the real bytes ran out the walk kept going, dereferencing the cursor past the end of the configuration buffer, in the host's context, whenever the application queried format or frame data.
Out-of-bounds Read
USBX HID Report Descriptor Heap OOB Read on Enumeration
CVE-2026-96582
4.9 - Medium
- October 20, 2026
A HID report descriptor is a sequence of items, each declaring in its header how many data bytes follow. The USBX host walks that sequence by advancing over each header and parsing the data behind it. The walk checked that an item fitted in the descriptor only **after** it had advanced past the header and parsed the payload, and the item analysis it relied on never measured the declared sizes against the bytes actually received. A HID peripheral returning a short report descriptor therefore drove a heap out-of-bounds read during ordinary enumeration.
Out-of-bounds Read
Eclipse FX_MEDIA OOB heap write via FAT image
CVE-2026-91041
7.8 - High
- October 20, 2026
Mounting an attacker-controlled FAT image with fault tolerance enabled causes an out-of-bounds heap write during log replay. The write is attacker-positioned and attacker-valued, and on a common embedded memory layout it reaches the FX_MEDIA driver callback, giving control of the instruction pointer.
Memory Corruption
DoS via Wild Pointer in ThreadX OSEK's CreateCounter()
CVE-2026-0648
7.8 - High
- January 27, 2026
The vulnerability stems from an incorrect error-checking logic in the CreateCounter() function (in threadx/utility/rtos_compatibility_layers/OSEK/tx_osek.c) when handling the return value of osek_get_counter(). Specifically, the current code checks if cntr_id equals 0u to determine failure, but @osek_get_counter() actually returns E_OS_SYS_STACK (defined as 12U) when it fails. This mismatch causes the error branch to never execute even when the counter pool is exhausted. As a result, when the counter pool is depleted, the code proceeds to cast the error code (12U) to a pointer (OSEK_COUNTER *), creating a wild pointer. Subsequent writes to members of this pointer lead to writes to illegal memory addresses (e.g., 0x0000000C), which can trigger immediate HardFaults or silent memory corruption. This vulnerability poses significant risks, including potential denial-of-service attacks (via repeated calls to exhaust the counter pool) and unauthorized memory access.
Incorrect Check of Function Return Value
Stack overflow via unchecked recursion in USBX Host Storage mount
CVE-2025-55095
4.2 - Medium
- January 27, 2026
The function _ux_host_class_storage_media_mount() is responsible for mounting partitions on a USB mass storage device. When it encounters an extended partition entry in the partition table, it recursively calls itself to mount the next logical partition. This recursion occurs in _ux_host_class_storage_partition_read(), which parses up to four partition entries. If an extended partition is found (with type UX_HOST_CLASS_STORAGE_PARTITION_EXTENDED or EXTENDED_LBA_MAPPED), the code invokes: _ux_host_class_storage_media_mount(storage, sector + _ux_utility_long_get(...)); There is no limit on the recursion depth or tracking of visited sectors. As a result, a malicious or malformed disk image can include cyclic or excessively deep chains of extended partitions, causing the function to recurse until stack overflow occurs.
Stack Overflow
ThreadX <6.4.3 Arbitrary Mem Read/Write via Weak Syscall Verification
CVE-2025-55080
- October 15, 2025
In Eclipse ThreadX before 6.4.3, when memory protection is enabled, syscall parameters verification wasn't enough, allowing an attacker to obtain an arbitrary memory read/write.
Improper Handling of Parameters
ThreadX DoS via Thread Priority Escalation (<6.4.3)
CVE-2025-55079
- October 15, 2025
In Eclipse ThreadX before version 6.4.3, the thread module has a setting of maximum priority. In some cases the check of that maximum priority wasn't performed, allowing, as a result, to obtain a thread with higher priority than expected and causing a possible denial of service.
Allocation of Resources Without Limits or Throttling
Eclipse ThreadX <6.4.3: DoS via Unchecked Memory Pointer
CVE-2025-55078
- October 14, 2025
In Eclipse ThreadX before version 6.4.3, an attacker can cause a denial of service (crash) by providing a pointer to a reserved or unmapped memory region. Vulnerable system calls had a check of pointers, but that check wasn't verifying whether the pointer is outside the module memory region.
Improper Handling of Parameters
ThreadX 6.3 Memory Overwrite via _Mtxinit() Array Overrun
CVE-2024-2214
7.8 - High
- March 26, 2024
In Eclipse ThreadX before version 6.4.0, the _Mtxinit() function in the Xtensa port was missing an array size check causing a memory overwrite. The affected file was ports/xtensa/xcc/src/tx_clib_lock.c
out-of-bounds array index
ThreadX<6.4.0: xQueueCreate Heap Ovfl in FreeRTOS API
CVE-2024-2212
7.8 - High
- March 26, 2024
In Eclipse ThreadX before 6.4.0, xQueueCreate() and xQueueCreateSet() functions from the FreeRTOS compatibility API (utility/rtos_compatibility_layers/FreeRTOS/tx_freertos.c) were missing parameter checks. This could lead to integer wraparound, under-allocations and heap buffer overflows.
Memory Corruption
Stay on top of Security Vulnerabilities
Want an email whenever new vulnerabilities are published for Eclipse Threadx or by Eclipse? Click the Watch button to subscribe.
