Katalog podatności CVE

W jądrze Linux w sterowniku i2c-imx ścieżka przerwaniowa odrzuca blokowy odczyt SMBus z liczbą bajtów 0 jako -EPROTO, ale nie wysyła NACK+STOP, co powoduje zablokowanie magistrali I2C. Poprawka akceptuje count=0 i wysyła NACK oraz STOP.

W jądrze Linux w module xfrm_interface brakuje wymogu CAP_NET_ADMIN w przestrzeni nazw sieciowych interfejsu podczas zmiany parametrów (changelink). Osoba z uprawnieniami tylko w jednej przestrzeni nazw może modyfikować interfejs w innej przestrzeni nazw, co narusza izolację.

W jądrze Linuxa odkryto podatność w sterownikach urządzeń znakowych TPM. Ze względu na pozostawione flagi FMODE_PREAD i FMODE_PWRITE, operacje odczytu/zapisu z przesunięciem (pread/pwrite) mogły prowadzić do odczytu poza zakresem pamięci sterty oraz zapisu zer poza zakresem. Problem rozwiązano przez wywołanie nonseekable_open(), co powoduje odrzucanie operacji pozycyjnych z błędem -ESPIPE.

W jądrze Linuxa wykryto podatność w sterowniku SPI dla układów i.MX (spi-imx). Gdy sterownik wybiera tryb DMA, ale nie może przygotować deskryptora DMA, następuje przełączenie na tryb PIO bez cofnięcia konfiguracji DMA, co prowadzi do uszkodzenia przesyłanych danych. Problem występuje m.in. na płytach i.MX8MP z TPM Infineon SLB9670, gdzie dane są przesunięte i urządzenie nie działa poprawnie.

W jądrze Linux w sterowniku spi-uniphier występuje problem z kolejnością inicjalizacji: funkcja devm_request_irq() jest wywoływana przed inicjalizacją kompletacji (completion) używanej przez procedurę obsługi przerwań. Może to prowadzić do wywołania complete() na niezainicjalizowanej kompletacji, co powoduje niezdefiniowane zachowanie (obserwowane przez KASAN).

W jądrze Linuxa w module CAN ISO-TP występuje problem z synchronizacją RCU w funkcji isotp_release(). Gdy NETDEV_UNREGISTER jest wywoływany jako pierwszy, funkcja pomija synchronizację, co może prowadzić do anulowania timera podczas wykonywania isotp_rcv() i ponownego jego uzbrojenia, powodując użycie po zwolnieniu. Poprawka polega na zawsze wywoływaniu synchronize_rcu() przed anulowaniem timerów.

W jądrze Linux wykryto podatność use-after-free w module CAN ISO-TP (can/isotp). Problem występuje podczas równoczesnego wyrejestrowywania interfejsu sieciowego (NETDEV_UNREGISTER) i zamykania gniazda (isotp_release), co może prowadzić do użycia zwolnionej pamięci.

W jądrze Linuxa w podsystemie CAN ISO-TP naprawiono podatność polegającą na braku synchronizacji stanów maszyny stanów transmisji (TX). Różne konteksty (sendmsg, ścieżka odbioru, timery) mogły działać na nieaktualnym stanie, co prowadziło do uszkodzenia niezwiązanych transferów. Poprawka polega na objęciu pełnego cyklu życia zgłoszenia TX blokadą so->rx_lock.

W jądrze Linuxa wykryto podatność w module CAN BCM (Broadcast Manager) prowadzącą do użycia po zwolnieniu (UAF) w timerze hrtimer. Problem wynika z pominięcia sprawdzenia flagi RX_NO_AUTOTIMER w szybkiej ścieżce odbioru pakietów, co pozwala na ponowne uzbrojenie timera po zaplanowaniu zwolnienia pamięci przez call_rcu(). Naprawa polega na przeniesieniu anulowania timerów i zwalniania pamięci do dedykowanej kolejki pracy (workqueue) oraz na utrzymaniu referencji do gniazda do czasu zakończenia tych operacji.

W jądrze Linux w module CAN BCM występuje wyścig (race condition) między odczytem pól bo->ifindex i bo->bound bez blokady a ich modyfikacją pod blokadą. Może to prowadzić do sytuacji, w której gniazdo powiązane z konkretnym interfejsem CAN zacznie też pasować do interfejsu 'dowolny'. Dodatkowo, funkcja bcm_rx_setup() może zwracać sukces, gdy urządzenie zniknie w trakcie, zamiast zgłosić błąd -ENODEV.

W jądrze Linux wykryto podatność w module CAN BCM (Broadcast Manager) polegającą na braku synchronizacji przy aktualizacji wartości timerów i filtrów. Jednoczesny dostęp do tych danych z wątków obsługujących ruch CAN może prowadzić do wyścigu, co skutkuje nieprawidłowym działaniem lub potencjalną eskalacją uprawnień.

W jądrze Linux w module CAN BCM brakuje poprawnych operacji listy RCU. Funkcje bcm_rx_setup() i bcm_tx_setup() nie używają list_add_rcu(), co może prowadzić do nieprawidłowej inicjalizacji struktury bcm_op podczas przeglądania listy przez bcm_proc_show(). Ponadto bcm_release() usuwa operacje bez list_del_rcu(), co może powodować problemy z synchronizacją.

W jądrze Linux w module CAN BCM rozszerzono użycie blokady bcm_tx_lock dla aktualizacji danych i timerów. Nowe dane ramek są najpierw walidowane w osobnym buforze, a dopiero potem kopiowane pod blokadą, co zapobiega obserwacji częściowo zaktualizowanych ramek. Dodano również obsługę błędów dla memcpy_from_msg() oraz przeniesiono aktualizacje timerów pod blokadę, eliminując rozdarcie odczytu 64-bitowych wartości na platformach 32-bitowych.

W jądrze Linux w module CAN BCM występuje problem z nieaktualnymi operacjami RX/TX po usunięciu urządzenia. Dla RX, aktualizacja RX_SETUP mogła pominąć ponowną rejestrację filtra, gdy urządzenie zostało usunięte, co powodowało, że filtr nie był aktywny. Dla TX, funkcja bcm_notify() nie obsługiwała tx_ops, co prowadziło do niekończącego się ponawiania timera i możliwości wstrzykiwania ramek do później używanego ifindex.

W jądrze Linux w module CAN BCM dodano śledzenie pojedynczego interfejsu źródłowego dla operacji ANYDEV z limitem czasu lub ograniczeniem prędkości. Wcześniej, gdy ramki pasowały z różnych interfejsów, mogło dochodzić do wyścigów i uszkodzenia danych. Teraz pierwszy interfejs, który dostarczy pasującą ramkę, jest zapamiętywany, a ramki z innych interfejsów są odrzucane.

W jądrze Linux w module CAN BCM brakuje walidacji długości ramki w funkcji bcm_rx_setup() dla odpowiedzi RTR. Funkcja bcm_tx_setup() sprawdza długość ramki, ale bcm_rx_setup() tego nie robi, co może prowadzić do nieprawidłowych danych.

W jądrze Linux w module CAN BCM brakuje odpowiedniego zliczania referencji urządzenia podczas usuwania filtra CAN. Funkcje bcm_release(), bcm_delete_rx_op() i bcm_notifier() polegały na ponownym wyszukiwaniu urządzenia po ifindex, co mogło zawieść przy równoczesnym wyrejestrowaniu urządzenia, pozostawiając nieaktualny filtr. Poprawka dodaje trzymanie referencji na op->rx_reg_dev od momentu rejestracji filtra do jego wyrejestrowania.

W jądrze Linuxa odkryto podatność w mechanizmie io_uring/bpf-ops, która pozwala na ponowną rejestrację już związanego zestawu operacji BPF. Atakujący z uprawnieniami CAP_BPF i CAP_PERFMON może doprowadzić do użycia po zwolnieniu (use-after-free) w kontekście io_uring, co może skutkować eskalacją uprawnień lub awarią systemu.

W jądrze Linuxa weryfikator BPF nie resetuje granic rejestru przed zawężeniem zakresu wartości zwracanej przez hook LSM, co może prowadzić do rozbieżności między weryfikacją a rzeczywistym wykonaniem. Atakujący może wykorzystać tę lukę do obejścia zabezpieczeń pamięci BPF.

W jądrze Linuxa podczas procesu fork() pole bpf_storage w strukturze zadania może nie zostać zainicjalizowane przed pewnymi ścieżkami błędu, co prowadzi do użycia niezainicjalizowanego wskaźnika. Może to powodować zawieszenie systemu lub użycie po zwolnieniu (UAF).