Katalog podatności CVE

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

W jądrze Linuxa w sterowniku sieciowym sparx5, jeśli alokacja kolejki pracy zakończy się niepowodzeniem, rejestracja notyfikatora blokującego nie jest cofnięta, co prowadzi do wycieku zasobów. Może to skutkować niestabilnością systemu lub awarią.

W jądrze Linux w module dm thin metadata wykryto podatność polegającą na niespójności metadanych podczas awarii zatwierdzania (commit) operacji rezerwacji lub zwalniania migawki metadanych. Modyfikacje pola held_root w superbloku są zapisywane bezpośrednio w buforze, a w przypadku niepowodzenia transakcji trafiają na dysk, powodując uszkodzenie metadanych.

W jądrze Linuxa w module dm-era występuje błąd poza zakresem pamięci przy niezerowym sektorze startowym. Obliczenia bloku zapisu nie uwzględniają offsetu, co może prowadzić do odczytu poza przydzieloną pamięcią (wykrywane przez KASAN).

W jądrze Linuxa w module dm-log występuje przepełnienie zmiennej bitset_size na maszynach 32-bitowych. Zaokrąglenie region_count do wielokrotności BITS_PER_LONG może spowodować zawinięcie do zera, co prowadzi do nieprawidłowej alokacji pamięci.

W jądrze Linuxa w module dm występuje wyciek klucza sesji (thread keyring) wywołującego przez plik urządzenia tabeli. Powoduje to, że klucz woluminu LUKS pozostaje w pamięci po operacji luksSuspend, co może umożliwić jego odzyskanie.

W jądrze Linux w funkcji dm_early_create występuje błąd polegający na próbie zwolnienia już użytej tabeli, gdy funkcja dm_resume zakończy się niepowodzeniem. Tabela została już zainicjowana przez dm_swap_table, a kod próbuje ją ponownie zniszczyć, co może prowadzić do nieprawidłowego działania. Poprawka pomija wywołanie dm_table_destroy w tym przypadku.