Vulnerability feed

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.

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.

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 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.

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 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).

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.

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 ULONGs 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.