CVE-2026-102757
WysokieCVSS 8.5Prawdopodobieństwo exploitacji (EPSS)
Niskie ryzykoPercentyl 1 - wyżej niż 1% wszystkich znanych CVE
Streszczenie
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.
Ocena ryzyka
Atakujący może usunąć izolację pamięci i uzyskać pełną kontrolę nad systemem, co prowadzi do całkowitego naruszenia bezpieczeństwa.
Rekomendacja
Zastosuj poprawkę od producenta ThreadX. Ogranicz możliwość ładowania modułów do zaufanych źródeł.
Inne podatności w ThreadX
Zobacz wszystkie- CVE-2026-95108Średnie
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.
- CVE-2026-95107Wysokie
Moduł ThreadX wybiera object_size podczas wywołania txm_module_object_allocate. Module Manager dodaje własny 16-bajtowy nagłówek prywatny do tego rozmiaru i żąda od puli obiektów wyniku bez sprawdzenia dodawania. Rozmiar bliski górnej granicy ULONG powoduje przepełnienie, pula zwraca blok znacznie mniejszy niż nagłówek, a manager zapisuje nagłówek poza końcem bloku, do sąsiedniego bloku puli bajtów.
- CVE-2026-94202Średnie
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.
- CVE-2026-94192Wysokie
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.
- CVE-2026-94024Średnie
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.
- CVE-2026-94023Średnie
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.
- CVE-2026-95111Średnie
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.
- CVE-2026-102711Średnie
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.
Oryginalny opis (angielski, źródło NVD)
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.
Dane podatności pochodzą z NVD (NIST) · CISA KEV · EPSS