Katalog podatności CVE

W jądrze Linux w module mac80211 funkcja ieee80211_8023_xmit() nie ustawia info->band z kontekstu kanału na interfejsach non-MLD, pozostawiając wartość 0. Powoduje to, że ieee80211_get_tx_rates() używa niewłaściwego pasma dla tych ramek.

W jądrze Linux w module mac80211 funkcja mesh_fast_tx_cache() przechowuje surowe wskaźniki mesh_path. Usunięcie ścieżki opróżnia pamięć podręczną i zwalnia ścieżkę przez kfree_rcu(), ale wyszukiwanie trzymające ścieżkę może wstawić nowy wpis po opróżnieniu, wskazując na zwolnioną pamięć (use-after-free).

W jądrze Linux w module mac80211 funkcja fils_encrypt_assoc_req() przyjmuje ramkę (Re)Association Request, której ostatnim elementem jest FILS Session, co daje zerową długość crypt_len i wywołanie aes_siv_encrypt() z pustym tekstem jawnym. kmemdup() zwraca ZERO_SIZE_PTR, a bezwarunkowe sg_init_one() umieszcza nieprawidłową stronę w scatterlist, co z CONFIG_DEBUG_SG wywołuje BUG jądra.

W jądrze Linux w podsystemie USB serial występuje wyścig przy wyrejestrowywaniu sterownika dynamicznych identyfikatorów. Dynamiczne identyfikatory są zwalniane przed wyrejestrowaniem sterownika i usunięciem atrybutu "new_id", co może prowadzić do wycieku identyfikatora dodanego przez równoległy zapis.

W jądrze Linux w podsystemie USB serial występuje nieprawidłowa kolejność wyrejestrowywania sterowników. Przy wyładowywaniu modułu sterownika USB należy go wyrejestrować przed sterownikami magistrali USB serial, aby zatrzymać I/O przed odłączeniem portów i uniknąć use-after-free w procedurach obsługi zakończenia.

W jądrze Linux w podsystemie USB serial ioctl tty mogą wyścignąć się z hangup i wywołać sterownik tty dla urządzenia, które już zniknęło lub zostało wyłączone. Brak synchronizacji i sprawdzeń może prowadzić do dereferencji wskaźnika NULL, zwłaszcza przy rozłączeniu urządzenia podczas długiego sygnalizowania break.

W jądrze Linux w podsystemie Thunderbolt występuje błąd use-after-free (użycie zwolnionej pamięci) podczas anulowania żądania kanału sterującego. Gdy funkcja tb_cfg_request_work() zakończy się tuż przed tb_cfg_request_cancel(), dochodzi do ponownego zakolejkowania tego samego zadania i dostępu do już zwolnionej pamięci. Problem został naprawiony poprzez zapewnienie, że anulowane żądanie nie jest przekazywane ani planowane do wykonania, a zwolnienie następuje w tb_cfg_request_cancel().

W jądrze Linux w sterowniku Thunderbolt funkcja tb_stop() zwalnia referencje do tuneli DP, ale ich nie dezaktywuje, przez co dprx_work może nadal działać po usunięciu routera. Prowadzi to do operowania na zwolnionych strukturach IDA i ostrzeżeń typu "ida_free called for id=8 which is not allocated". Problem można wywołać odłączając sterownik, gdy tunel DP wciąż czeka na zakończenie odczytu możliwości DPRX.

W jądrze Linux w sterowniku Thunderbolt funkcja tb_tunnel_alloc_dp() przyjmuje opcjonalny callback uruchamiany z dprx_work po zakończeniu odczytu możliwości DPRX. Bez tego callbacku referencja do tunelu jest wyciekana, ponieważ nie jest zwalniana. Problem dotyczy tuneli z tb_tunnel_discover_dp(), które są aktywowane przy przywracaniu z hibernacji.

W jądrze Linux w sterowniku Thunderbolt funkcja tb_stop() usuwa tylko tunele DMA, więc tunel DP oczekujący na dprx_work pozostaje w kolejce, gdy routery są usuwane i kanał sterowania zatrzymywany. flush_workqueue() w tb_domain_remove() nie czeka na jego końcowe uruchomienie, a callback działa na już zniszczonej domenie, co blokuje unbind do momentu przekroczenia limitu czasu.

W jądrze Linux w sterowniku Thunderbolt funkcja tb_tunnel_one_dp() pobiera referencję do domeny, która jest zwalniana dopiero po uruchomieniu tb_dp_tunnel_active() w kolejce roboczej. Jeśli praca zostanie anulowana, referencja jest wyciekana, co od commitu f5cc545f5969 powoduje również wieczne blokowanie w oczekiwaniu na zakończenie przy odłączaniu sterownika.

W jądrze Linux w sterowniku Thunderbolt funkcja tb_dp_dprx_work() sprawdza flagę ->dprx_canceled przed pobraniem tb->lock, przez co może przeoczyć tb_dp_dprx_stop(), które nie mogło anulować już działającej pracy. W efekcie odpytuje możliwości DPRX i uruchamia callback dla tunelu, który został już zniszczony podczas zawieszania lub usuwania domeny.

W jądrze Linux w podsystemie Thunderbolt występuje wyścig między tb_remove_work() a tb_domain_remove(), który prowadzi do dereferencji wskaźnika NULL tb->root_switch w funkcji tb_free_unplugged_xdomains(). Problem wynika z niewłaściwego przeniesienia wywołania tb_free_unplugged_xdomains() poza sekcję chronioną mutexem tb->lock bez sprawdzenia, czy tb->root_switch nie jest NULL.

W jądrze Linux w sterowniku Thunderbolt funkcja tb_xdp_properties_request() rezerwuje miejsce na 45 dwordów danych w buforze odpowiedzi 252 bajtów, ale sześciobitowe pole długości XDomain może zostać ustawione przez złośliwego peera na 63, co jest interpretowane jako 48 dwordów danych. Prowadzi to do 12-bajtowego odczytu poza granicami sterty z tablicy res->data.

W jądrze Linux w kliencie SMB funkcja smb3_zero_range() usuwała pagecache tylko dla zakresu zerowanego, więc przy rozszerzaniu pliku folio obejmujące stary EOF — mogące zawierać dane zabrudzone poza EOF przez mmap — nie było usuwane i stawało się widoczne jako zawartość pliku po jego rozszerzeniu.

W jądrze Linux w kliencie SMB funkcja cifs_remap_file_range() usuwała pagecache tylko dla folio nakładających się na region docelowy, więc przy klonowaniu rozszerzającym plik folio obejmujące stary EOF — mogące zawierać dane zabrudzone poza EOF przez mmap — nie było usuwane i stawało się widoczne jako zawartość pliku po jego rozszerzeniu.

W kliencie SMB w jądrze Linux, emulacja fallocate dla małych wewnętrznych zakresów (tryb 0 / FALLOC_FL_KEEP_SIZE) wywoływała FSCTL_QUERY_ALLOCATED_RANGES bez uprzedniego opróżnienia danych. Wbrew dokumentacji Win32 zapytanie to nie jest spójne z niedawno zapisanymi danymi, przez co serwer mógł zgłosić zapisany zakres jako nieprzydzielony i emulacja nadpisywała aktywne dane zerami. Problem dotyczy serwerów Windows; Samba nie wykazuje tego zachowania.

W kliencie SMB w jądrze Linux funkcja smb3_zero_range() zerowała zakres bez uprzedniego opróżnienia brudnych danych, gdy zakres nie sięgał końca pliku. Brudne strony mogły zostać zapisane na serwer po wykonaniu FSCTL_SET_ZERO_DATA i nadpisać wyzerowany obszar nieaktualnymi danymi.

W kliencie SMB jądra Linux ścieżki kopiowania po stronie serwera (cifs_file_copychunk_range) oraz klonowania (FICLONE w cifs_remap_file_range) nie blokowały pamięci podręcznej stron celu w sposób stosowany przez inne operacje zakresowe. W efekcie asynchroniczny zapis zwrotny mógł zakończyć się po wykonaniu kopiowania/klonowania i nadpisać świeżo zapisane dane nieaktualną treścią, uszkadzając plik.

W strukturze cifsFileInfo klienta SMB w jądrze Linux kilka flag (invalidHandle, swapfile, oplock_break_cancelled, offload, status_file_deleted) dzieliło ten sam bajt pola bitowego i było aktualizowanych w różnych ścieżkach kodu pod różnymi blokadami. Operacje read-modify-write na poziomie bajtu mogły nadpisywać równoczesne zmiany innych flag.