CVE-2026-95107

W ThreadX menedżer modułów przy usuwaniu wątku zwalniał tylko pierwszą z dwóch alokacji (blok kontrolny TX_THREAD i stos jądra TXM_MODULE_KERNEL_STACK_SIZE). Stos jądra pozostawał zajęty do zatrzymania całego modułu, więc moduł tworzący i usuwający wątki w pętli wyczerpywał współdzieloną pulę obiektów, uniemożliwiając tworzenie nowych obiektów jądra i wątków modułów w całym systemie.

Dyspozytor tworzenia puli bloków w menedżerze modułów ThreadX weryfikował tylko dwa słowa ALIGN_TYPE tablicy parametrów dostarczonej przez moduł chroniony pamięciowo, a następnie używał indeksów 0–3. Jedno z niezweryfikowanych słów jest odczytywane przez samą kontrolę zakresu (indeks 1 jako początek puli, indeks 2 jako długość), co powoduje odczyt poza granicami wykonywany przez kod walidacji przed dotarciem do usługi jądra.

Moduł ThreadX alokuje bloki kontrolne swoich obiektów jądra z puli obiektów Module Managera i może zażądać zwrotu tej pamięci przez adres za pomocą txm_module_object_deallocate. Manager zwalnia ją niezależnie od zawartości, w tym blok kontrolny wciąż używany przez jądro. Dealokacja nie jest usunięciem: obiekt pozostaje na liście utworzonych, wątek pozostaje na liście gotowych lub zawieszonych i pozostaje planowalny, a aktywny timer pozostaje na liście timerów, podczas gdy pula bajtów może przydzielić te same bajty kolejnej alokacji.

W menedżerze modułów ThreadX wyszukiwanie obiektów walidowało tylko jeden bajt nazwy wyszukiwania modułu chronionego pamięciowo, a następnie przeglądało ją w trybie uprzywilejowanym z podniesionym licznikiem wywłaszczania. Funkcja txm_module_object_pointer_get_extended otrzymuje długość, ale jej nie używa do ograniczenia bufora, a przestarzała txm_module_object_pointer_get przekazuje maksymalną wartość UINT, usuwając ograniczenie.

Warstwa dyspozytora menedżera modułów ThreadX przy usuwaniu obiektu jądra sprawdzała jedynie, czy wskaźnik wskazuje poza kod i dane modułu — co jest polityką używania, a nie niszczenia obiektów. Moduł mógł wskazać dowolny obiekt, do którego miał wskaźnik (w tym obiekty utworzone przez aplikację lub inne moduły), i zlecić uprzywilejowanemu dyspozytorowi jego usunięcie.

W module ThreadX z ochroną pamięci żądanie kolejki trafia do warstwy dyspozytorskiej Module Managera, która przekazuje liczbę słów zamiast liczby bajtów do sprawdzenia zakresu. Powoduje to odczyt w trybie uprzywilejowanym do 3 * message_size bajtów poza dozwolony obszar pamięci modułu, a odczytane dane trafiają do obszaru komunikatów kolejki.

Dwa problemy w loaderze modułów ładowalnych ThreadX, osiągalne gdy urządzenie ładuje moduł kontrolowany przez atakującego przez `_txm_module_manager_memory_load` / `_txm_module_manager_in_place_load`. API przyjmują tylko wskaźnik bazowy bez długości obrazu, więc wszystkie pola rozmiaru/przesunięcia w `TXM_MODULE_PREAMBLE` są w pełni kontrolowane przez atakującego: (1) odczyt poza granicami sterty oraz (2) luka w integralności przepływu sterowania.

Nieuprzywilejowany moduł ThreadX chroniony pamięcią może spowodować, że jądro odczyta i zapisze pamięć pod wybranymi przez siebie adresami w trybie uprzywilejowanym, a następnie użyć tego do wyczyszczenia bitu włączenia MPU i usunięcia własnej izolacji. Menedżer modułów decydował, czy uprzywilejowana usługa może wyłuskać adres obiektu, pytając tylko, czy adres ten znajduje się poza modułem. Pula obiektów menedżera znajduje się poza każdym modułem, więc test był spełniony przez adres przesunięty do wnętrza jednej z własnych uprzywilejowanych alokacji modułu, co nie oznacza żadnego obiektu. Bajty, które taki adres przedstawia jako blok kontrolny, to bajty, które moduł umieścił tam za pomocą zwykłych usług tworzenia i ustawiania, więc identyfikator bloku kontrolnego na ich początku mógł być odczytany jako dowolny typ wybrany przez moduł, a test identyfikatora warstwy `_txe_` się zgadzał. Zgłoszony łańcuch używa tego do osiągnięcia uprzywilejowanego `memset` w zakresie wybranym przez atakującego.