CVE-2026-94024

In ThreadX, the module manager's thread-delete dispatcher released only the first of two allocations (the TX_THREAD control block and the TXM_MODULE_KERNEL_STACK_SIZE kernel stack). The kernel stack stayed allocated until the whole module was stopped, so a module creating and deleting threads in a loop exhausted the shared object pool, preventing creation of new kernel objects and module threads system-wide.

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.

The block-pool create dispatcher in the ThreadX module manager validated only two ALIGN_TYPE words of the extra-parameter array supplied by a memory-protected module, then used indices 0 through 3. One unvalidated word is read by the dispatcher's own range check (index 1 as pool start, index 2 as length), so the out-of-bounds read is performed by the validation code before reaching the kernel service.

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.

The ThreadX module manager's dispatch layer, when reaching a kernel object's delete service, only checked whether the pointer lay outside the module's own code and data — the policy for using an object, not destroying it. A module could name any object it had a pointer to (including objects created by the application or other modules) and have the privileged dispatcher delete it.

In a memory-protected ThreadX module, a queue request reaches the Module Manager's dispatch layer, which passes a word count instead of a byte extent to the range check. This causes a privileged read of up to 3 * message_size bytes past the module's allowed memory, with the data written into the queue's message area.

Two issues in the ThreadX loadable-module loader, reachable when a device loads an attacker-controlled module object via `_txm_module_manager_memory_load` / `_txm_module_manager_in_place_load`. These APIs take only a base pointer with no image length, so every size/offset field in `TXM_MODULE_PREAMBLE` is fully attacker-trusted: (1) a heap OOB read and (2) a control-flow-integrity gap.

An unprivileged, memory-protected ThreadX module can have the kernel read and write memory at addresses of its choosing, in privileged mode, and can use that to clear the MPU enable bit and remove its own isolation boundary. The Module Manager decided whether a privileged service could dereference an object address a module named by asking only whether that address fell outside the module. The manager's object pool is outside every module, so the test was satisfied by an address shifted into the interior of one of the module's own privileged allocations, which denotes no object at all. The bytes such an address presents as a control block are bytes the module put there through ordinary create and set services, so the control block ID at the front of them could be made to read as any type the module chose, and the `_txe_` layer's ID test then agreed. The reported chain uses that to reach a privileged `memset` across an attacker-chosen range.