Katalog podatności CVE

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.

W jądrze Linux w module dm-integrity występuje błąd, który może prowadzić do zakleszczenia. Gdy funkcja dm_integrity_check_limits zakończy się niepowodzeniem, kod wychodzi z DM_MAPIO_KILL, ale zakres jest już zablokowany i nie jest odblokowywany. Poprawka przenosi sprawdzenie limitów wcześniej, aby uniknąć wycieku zasobów.

W jądrze Linux w module dm-integrity występuje błąd polegający na podwójnym zwiększaniu zmiennej hash_offset. Zmienna jest już zwiększana w pętli, a kod zwiększa ją ponownie, co prowadzi do nieprawidłowego działania. Poprawka usuwa dodatkowe zwiększenie.

W jądrze Linux funkcja dma_fence_dedup_array() zwraca 1, gdy wywołana z liczbą 0, co jest niezgodne z dokumentacją i może prowadzić do wyłuskania niezainicjalizowanego wskaźnika w amdgpu_userq_wait_*(). Poprawka sprawia, że funkcja zwraca 0 dla pustej tablicy.

W jądrze Linux w module accel/amdxdna występuje błąd use-after-free w funkcji amdxdna_gem_dmabuf_mmap(). Gdy vm_insert_pages() zawiedzie, ścieżka błędu wywołuje close, który zwalnia obiekt GEM, a następnie kod ponownie go zwalnia, co prowadzi do dostępu do zwolnionej pamięci. Poprawka polega na bezpośrednim powrocie z close_vma.