CVE-2026-102709

W Eclipse ThreadX w wersjach od 6.0.1 do 6.5.2.202603 moduł Module Manager pozwala modułowi działającemu w trybie użytkownika z ochroną pamięci wysłać sfałszowane żądanie callbacku do kolejki callbacków innego modułu. Wątek callbacku odbierającego modułu wywołuje wskaźnik funkcji z żądania bez sprawdzenia, czy pochodzi ono od Module Managera, więc kod atakującego wykonuje się z uprawnieniami odbierającego modułu; gdy moduł ten działa w trybie uprzywilejowanym, moduł użytkownika zyskuje wykonanie uprzywilejowane.

W Eclipse ThreadX w wersjach od 6.0.1 do 6.5.2.202603 mechanizm ThreadX Modules nie unieważnia callbacku przepełnienia bufora śledzenia modułu, gdy moduł zostanie zatrzymany i wyładowany. Przy włączonym śledzeniu zdarzeń i aktywnym buforze śledzenia należącym do jądra późniejsze zawinięcie bufora wywołuje callback z kontekstu uprzywilejowanego wątku po zwolnieniu kodu modułu, więc kod modułu użytkownika może zostać wykonany z uprawnieniami jądra po wyładowaniu lub, po ponownym użyciu pamięci, przekierować przepływ sterowania bądź spowodować błąd.

W Eclipse ThreadX w wersjach od 6.0.1 do 6.5.2.202603 usługi zarządzania wątkami Module Managera nie sprawdzają, czy wątek przekazany przez moduł w trybie użytkownika z ochroną pamięci należy do tego modułu. Każdy załadowany moduł może zawieszać, wznawiać, kończyć, resetować lub zmieniać priorytet wątków aplikacji i innych modułów oraz przerywać ich oczekiwania.

W Eclipse ThreadX w wersjach od 6.0.1 do 6.5.2.202603 handler PendSV portów Cortex-M zapisuje rejestry wywłaszczonego wątku modułu w trybie użytkownika w trybie uprzywilejowanym pod adresami pobranymi ze wskaźnika stosu wątku, bez sprawdzania tego wskaźnika względem stosu wątku. Moduł w trybie użytkownika z ochroną pamięci może zapisać do dziewięciu słów w pamięć poniżej dowolnego regionu, do którego może pisać, i odczytać, co jest tam przechowywane.

W Eclipse ThreadX w wersjach od 6.0.1 do 6.5.2.202603 loadery Module Manager zwracają błąd przepełnienia bez zwolnienia muteksu Module Manager, gdy preambuła modułu deklaruje rozmiar danych lub stosu powodujący przepełnienie arytmetyki alokacji. Załadowanie takiego obrazu blokuje wszystkie późniejsze operacje ładowania, uruchamiania, zatrzymywania i wyładowywania modułów z innych wątków aż do resetu systemu.

W menedżerze modułów Eclipse ThreadX (wersje 6.0.1–6.5.2.202603) loadery przyjmują obraz modułu bez jego długości i ufają rozmiarom oraz offsetom w jego preambule. Spreparowany obraz modułu może zadeklarować rozmiar kodu większy niż obraz, uzyskać dostęp do pamięci następującej po nim lub umieścić punkty wejścia poza swoim kodem.

W Eclipse ThreadX w wersjach 6.0.1 do 6.5.2.202603, zbudowanych z TX_ENABLE_EVENT_TRACE, Module Manager pozwala modułowi w trybie użytkownika z ochroną pamięci zarejestrować dowolny wskaźnik funkcji jako callback pełnego bufora śledzenia jądra. Złośliwy moduł może dzięki temu wykonać własny kod z uprawnieniami jądra, obchodząc izolację modułów, lub uszkodzić jądro nieprawidłowym wskaźnikiem.

W Eclipse ThreadX przed wersją 6.4.3, gdy włączona jest ochrona pamięci, weryfikacja parametrów wywołań systemowych była niewystarczająca, co pozwala atakującemu na uzyskanie dowolnego odczytu/zapisu pamięci.

W Eclipse ThreadX przed wersją 6.4.3 moduł wątków ma ustawienie maksymalnego priorytetu. W niektórych przypadkach sprawdzenie tego maksymalnego priorytetu nie zostało wykonane, co pozwala na uzyskanie wątku o wyższym priorytecie niż oczekiwano i może spowodować odmowę usługi.

W Eclipse ThreadX przed wersją 6.4.3 atakujący może wywołać odmowę usługi (awarię) poprzez podanie wskaźnika do zarezerwowanego lub niezamapowanego obszaru pamięci. Podatne wywołania systemowe sprawdzały wskaźniki, ale weryfikacja nie obejmowała sprawdzenia, czy wskaźnik znajduje się poza obszarem pamięci modułu.