Eclipse Threadx
Monthly
Integer overflow in the Eclipse ThreadX module manager lets a loaded module under-allocate an object-pool block and corrupt the adjacent byte-pool block. When a module calls txm_module_object_allocate with an object_size near ULONG_MAX, the manager's unchecked addition of its fixed 16-byte private header wraps, so the pool serves a block smaller than the header and the subsequent header write spills past its end into the neighbouring allocation. The issue is locally exploitable by a low-privileged attacker who already has code running inside a loaded module, affects only builds that compile in and use the ThreadX module subsystem, requires no user interaction, and no public exploit code was identified at time of analysis (no CISA KEV listing was provided).
Eclipse ThreadX's Cortex-A7 MMU module port accepts a caller-supplied buffer range after validating only its first byte, so an authenticated local attacker who can execute code in a protected module can cause privileged dispatch code to read or write beyond the module's declared memory. The weakness sits in a shared range-check macro used by protected-module dispatchers that consume buffers or extra-parameter arrays, and exposure is limited to systems running the ThreadX Module Manager with memory-protected modules on that port. No public exploit identified at time of analysis, and the attack path is local rather than remote or unauthenticated.
Eclipse ThreadX firmware built with Module Manager and loadable modules enabled contains a use-after-free in txm_module_object_deallocate: a module can request release of a kernel object control block by address, and the manager frees it even if the kernel still references it. The object remains on its created list and, for threads or timers, on scheduler/timer lists, so the byte pool can reallocate the same memory while the kernel still uses it. Exploitation requires local low-privilege code execution inside a loaded module (PR:L, AV:L) and is not remotely reachable in default builds; no public exploit code was identified at time of analysis.
Out-of-bounds read in the Eclipse ThreadX Module Manager's block-pool create dispatcher (_txm_module_manager_tx_block_pool_create_dispatch) lets a loaded, memory-protected module cause the kernel to read words it does not own. The dispatcher verifies only two ALIGN_TYPE words of the caller-supplied extra-parameter array, but then uses indices 0 through 3, and the out-of-bounds access happens inside the validation path itself: index 1 is taken as the pool start and index 2 as the length used to range-check it, so the size the pool start is checked against is itself an unverified word, and a further unverified word is consumed when the service argument list is built. Affected are builds using the ThreadX Module Manager with MPU-isolated modules; the vector is CVSS:4.0/AV:L/AC:L/PR:L/UI:N/VC:L/VI:N/VA:L (4.8) and our independent assessment agrees it is local, requires an already-loaded low-privilege module, and is bounded to information disclosure plus possible fault rather than code execution. No public exploit identified at time of analysis, and the issue is not in CISA KEV.
Denial of service in the Eclipse ThreadX Module Manager (CWE-400) lets a loaded user-mode module permanently drain the shared module object pool by cycling threads. Each thread a module creates consumes two allocations - a TX_THREAD control block plus a separately allocated TXM_MODULE_KERNEL_STACK_SIZE kernel stack - but the thread-delete dispatcher releases only the control block, so every valid create/terminate/delete cycle silently removes one fixed-size block from a finite pool shared by the Module Manager and all other loaded modules. A module that loops this lifecycle long enough exhausts the pool, after which no memory-protected module anywhere in the system can create kernel objects or new user-mode threads. Exploitation requires local execution of a loadable user-mode module (PR:L per the assessed CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H vector) and is purely an availability impact; no public exploit code or confirmed active exploitation was identified at time of analysis.
A crafted ThreadX module can permanently hang the entire kernel by abusing the Module Manager's object-lookup path: the search name for a memory-protected module is validated on only one byte and then walked in privileged mode for as far as the module declares. Both lookup dispatchers are affected - the recommended txm_module_object_pointer_get_extended accepts a length argument but never uses it to bound the buffer, while the deprecated txm_module_object_pointer_get passes the maximum UINT value, removing the bound entirely - so a hostile module forces an out-of-bounds read (CWE-125) without needing to know anything about the memory it reaches. Because the walk happens with the kernel's preemption count raised, an unrecoverable read fault leaves the scheduler disabled for the remainder of the device's uptime, making this a durable denial of service rather than privilege escalation or code execution. The local attack vector (CVSS 4.0 base 6.9; assessed 3.1 AV:L/AC:L/PR:L/UI:N/S:U/C:L/I:N/A:H) requires the attacker to already be able to load or compromise a module in a build that enables the Module Manager; no public exploit code has been identified at time of analysis and there is no confirmed active exploitation (no CISA KEV listing).
Eclipse ThreadX deployments that use the Module Manager to load untrusted or mixed-trust modules let a module destroy kernel objects it does not own: the privileged dispatcher validates only that a pointer targets memory outside the caller's own code and data, which is the correct policy for *using* a shared object but not for deleting one. Any code running inside a loaded module, having obtained a pointer (for example via txm_module_object_pointer_get_extended name lookup) to an application- or peer-module-owned queue, semaphore, or mutex, can route that pointer to the kernel object delete service and have it torn down, yielding a local integrity and availability impact (CVSS 4.0 6.9; CVSS 3.1 AV:L/PR:L/UI:N/I:H/A:H, no confidentiality impact). Exploitation requires the module feature to be enabled with more than one trust domain, is local only, and does not apply to firmware built as a single monolithic trusted image; no public exploit code has been identified at time of analysis and the issue is not in CISA KEV.
Eclipse ThreadX's memory-protected module support under-validates queue extents in the front-send path: the Module Manager's dispatch layer receives a value counted in ULONGs where it expects a byte extent, so the privileged copy in _txe_queue_front_send reads up to 3 x message_size bytes past the end of the memory a loaded module is permitted to read. The over-read words land in the queue's message area, meaning a second module (or the same one) that can receive from that queue can retrieve the adjacent memory contents. Exploitation is strictly local and requires the attacker to already control a loaded low-privilege module authorized to front-send on the target queue; there is no public exploit code and no confirmed active exploitation (no public exploit identified at time of analysis), and the assessed impact is limited information disclosure plus a possible availability effect, consistent with the 4.8 CVSS 4.0 / 4.8 CVSS 3.1 ratings.
Integer overflow in the Eclipse ThreadX module manager lets a loaded module under-allocate an object-pool block and corrupt the adjacent byte-pool block. When a module calls txm_module_object_allocate with an object_size near ULONG_MAX, the manager's unchecked addition of its fixed 16-byte private header wraps, so the pool serves a block smaller than the header and the subsequent header write spills past its end into the neighbouring allocation. The issue is locally exploitable by a low-privileged attacker who already has code running inside a loaded module, affects only builds that compile in and use the ThreadX module subsystem, requires no user interaction, and no public exploit code was identified at time of analysis (no CISA KEV listing was provided).
Eclipse ThreadX's Cortex-A7 MMU module port accepts a caller-supplied buffer range after validating only its first byte, so an authenticated local attacker who can execute code in a protected module can cause privileged dispatch code to read or write beyond the module's declared memory. The weakness sits in a shared range-check macro used by protected-module dispatchers that consume buffers or extra-parameter arrays, and exposure is limited to systems running the ThreadX Module Manager with memory-protected modules on that port. No public exploit identified at time of analysis, and the attack path is local rather than remote or unauthenticated.
Eclipse ThreadX firmware built with Module Manager and loadable modules enabled contains a use-after-free in txm_module_object_deallocate: a module can request release of a kernel object control block by address, and the manager frees it even if the kernel still references it. The object remains on its created list and, for threads or timers, on scheduler/timer lists, so the byte pool can reallocate the same memory while the kernel still uses it. Exploitation requires local low-privilege code execution inside a loaded module (PR:L, AV:L) and is not remotely reachable in default builds; no public exploit code was identified at time of analysis.
Out-of-bounds read in the Eclipse ThreadX Module Manager's block-pool create dispatcher (_txm_module_manager_tx_block_pool_create_dispatch) lets a loaded, memory-protected module cause the kernel to read words it does not own. The dispatcher verifies only two ALIGN_TYPE words of the caller-supplied extra-parameter array, but then uses indices 0 through 3, and the out-of-bounds access happens inside the validation path itself: index 1 is taken as the pool start and index 2 as the length used to range-check it, so the size the pool start is checked against is itself an unverified word, and a further unverified word is consumed when the service argument list is built. Affected are builds using the ThreadX Module Manager with MPU-isolated modules; the vector is CVSS:4.0/AV:L/AC:L/PR:L/UI:N/VC:L/VI:N/VA:L (4.8) and our independent assessment agrees it is local, requires an already-loaded low-privilege module, and is bounded to information disclosure plus possible fault rather than code execution. No public exploit identified at time of analysis, and the issue is not in CISA KEV.
Denial of service in the Eclipse ThreadX Module Manager (CWE-400) lets a loaded user-mode module permanently drain the shared module object pool by cycling threads. Each thread a module creates consumes two allocations - a TX_THREAD control block plus a separately allocated TXM_MODULE_KERNEL_STACK_SIZE kernel stack - but the thread-delete dispatcher releases only the control block, so every valid create/terminate/delete cycle silently removes one fixed-size block from a finite pool shared by the Module Manager and all other loaded modules. A module that loops this lifecycle long enough exhausts the pool, after which no memory-protected module anywhere in the system can create kernel objects or new user-mode threads. Exploitation requires local execution of a loadable user-mode module (PR:L per the assessed CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H vector) and is purely an availability impact; no public exploit code or confirmed active exploitation was identified at time of analysis.
A crafted ThreadX module can permanently hang the entire kernel by abusing the Module Manager's object-lookup path: the search name for a memory-protected module is validated on only one byte and then walked in privileged mode for as far as the module declares. Both lookup dispatchers are affected - the recommended txm_module_object_pointer_get_extended accepts a length argument but never uses it to bound the buffer, while the deprecated txm_module_object_pointer_get passes the maximum UINT value, removing the bound entirely - so a hostile module forces an out-of-bounds read (CWE-125) without needing to know anything about the memory it reaches. Because the walk happens with the kernel's preemption count raised, an unrecoverable read fault leaves the scheduler disabled for the remainder of the device's uptime, making this a durable denial of service rather than privilege escalation or code execution. The local attack vector (CVSS 4.0 base 6.9; assessed 3.1 AV:L/AC:L/PR:L/UI:N/S:U/C:L/I:N/A:H) requires the attacker to already be able to load or compromise a module in a build that enables the Module Manager; no public exploit code has been identified at time of analysis and there is no confirmed active exploitation (no CISA KEV listing).
Eclipse ThreadX deployments that use the Module Manager to load untrusted or mixed-trust modules let a module destroy kernel objects it does not own: the privileged dispatcher validates only that a pointer targets memory outside the caller's own code and data, which is the correct policy for *using* a shared object but not for deleting one. Any code running inside a loaded module, having obtained a pointer (for example via txm_module_object_pointer_get_extended name lookup) to an application- or peer-module-owned queue, semaphore, or mutex, can route that pointer to the kernel object delete service and have it torn down, yielding a local integrity and availability impact (CVSS 4.0 6.9; CVSS 3.1 AV:L/PR:L/UI:N/I:H/A:H, no confidentiality impact). Exploitation requires the module feature to be enabled with more than one trust domain, is local only, and does not apply to firmware built as a single monolithic trusted image; no public exploit code has been identified at time of analysis and the issue is not in CISA KEV.
Eclipse ThreadX's memory-protected module support under-validates queue extents in the front-send path: the Module Manager's dispatch layer receives a value counted in ULONGs where it expects a byte extent, so the privileged copy in _txe_queue_front_send reads up to 3 x message_size bytes past the end of the memory a loaded module is permitted to read. The over-read words land in the queue's message area, meaning a second module (or the same one) that can receive from that queue can retrieve the adjacent memory contents. Exploitation is strictly local and requires the attacker to already control a loaded low-privilege module authorized to front-send on the target queue; there is no public exploit code and no confirmed active exploitation (no public exploit identified at time of analysis), and the assessed impact is limited information disclosure plus a possible availability effect, consistent with the 4.8 CVSS 4.0 / 4.8 CVSS 3.1 ratings.