In Eclipse ThreadX versions 6.0.1 through 6.5.2.202603, the Module Manager lets a user-mode, memory-protected module post a forged callback request to another module's callback request queue. The receiving module's callback thread calls the function pointer in the request without checking that the Module Manager sent it, so the attacker's code runs with the receiving module's privilege; when that module runs in privileged mode, a user-mode module gains privileged execution.

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/txcliblock.c

In Eclipse ThreadX before 6.4.0, xQueueCreate() and xQueueCreateSet() functions from the FreeRTOS compatibility API (utility/rtoscompatibilitylayers/FreeRTOS/txfreertos.c) were missing parameter checks. This could lead to integer wraparound, under-allocations and heap buffer overflows.

The vulnerability stems from an incorrect error-checking logic in the CreateCounter() function (in threadx/utility/rtoscompatibilitylayers/OSEK/txosek.c) when handling the return value of osekgetcounter(). Specifically, the current code checks if cntrid equals 0u to determine failure, but @osekgetcounter() actually returns EOSSYSSTACK (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 (OSEKCOUNTER ), 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.

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.

In Eclipse ThreadX versions 6.0.1 through 6.5.2.202603, the PendSV handler of the Cortex-M module ports saves a preempted user-mode module thread's registers in privileged mode at addresses taken from the thread's stack pointer, without checking that pointer against the thread's stack. A user-mode, memory-protected module can thereby write up to nine words, eight of its choosing, or 25 with floating-point state, into memory immediately below any region it may write, and read back what is stored there.

In Eclipse ThreadX versions 6.0.1 through 6.5.2.202603, the Module Manager's thread-control services do not check that a thread passed by a user-mode, memory-protected module belongs to that module. Any loaded module can suspend, resume, terminate, reset or re-prioritise application threads and other modules' threads and abort their waits, denying service or changing how the system schedules them.

In Eclipse ThreadX versions 6.0.1 through 6.5.2.202603, the Module Manager's thread-control services do not check that a thread passed by a user-mode, memory-protected module belongs to that module. Any loaded module can suspend, resume, terminate, reset or re-prioritise application threads and other modules' threads and abort their waits, denying service or changing how the system schedules them.

In Eclipse ThreadX versions 6.0.1 through 6.5.2.202603, the Module Manager loaders return an overflow error without releasing the Module Manager mutex when a module preamble declares a data or stack size that overflows the allocation arithmetic. Loading such an image blocks every later module load, start, stop and unload from other threads until the system is reset.

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.

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.