Katalog podatności CVE

W jądrze Linux funkcja i3c_master_unregister_i3c_devs() czyści i3cdev->dev->desc przed wywołaniem device_unregister(). Podczas wyrejestrowania i3c_device_uevent() oraz wyścigowy modalias_show() mogą zobaczyć NULL desc i użyć niezainicjalizowanej struktury na stosie, ujawniając zawartość stosu jądra. Może też wystąpić use-after-free przy zapisie desc po zwolnieniu urządzenia.

W jądrze Linux funkcja svc_i3c_master_handle_ibi() odczytuje ładunek IBI z RX FIFO do slotu, ograniczając pętlę rozmiarem FIFO (SVC_I3C_FIFO_SIZE), a nie rozmiarem slotu. Sterownik może zażądać mniejszego max_payload_len (np. mctp-i3c żąda 1), więc urządzenie wysyłające więcej bajtów powoduje zapis poza slot->data, czyli out-of-bounds write do puli IBI.

W jądrze Linux sterownik Renesas I3C używa modelu asynchronicznego: przygotowuje strukturę renesas_i3c_xfer, kolejkuje ją i czeka na zakończenie. Jeśli wystąpi przekroczenie czasu, wątek oczekujący usuwa transfer z kolejki i zwalnia go; późniejsze przerwanie może odwołać się do zwolnionej pamięci, powodując awarię.

W jądrze Linux funkcja brcmf_sdio_read_control() nie zwalnia pamięci przydzielonej dla buf w niektórych ścieżkach błędów. Poprawka polega na dodaniu wywołań vfree() w tych ścieżkach.

W jądrze Linux funkcja iwl_op_mode_dvm_start() w sterowniku iwlwifi dvm: skok do out_free_eeprom pomija etykietę out_free_eeprom_blob. W efekcie ścieżki błędów po pomyślnym sparsowaniu EEPROM zwalniają priv->nvm_data, ale wycieka priv->eeprom_blob. Poprawka zmienia kolejność etykiet obsługi błędów.

W jądrze Linux w sterowniku wifi rtl8xxxu występuje błąd use-after-free związany z kolejką roboczą rx_urb_wq. Funkcja rtl8xxxu_stop() nie anuluje rx_urb_wq, więc worker może wykonać się po zwolnieniu struktury priv przez rtl8xxxu_disconnect(), co prowadzi do użycia zwolnionej pamięci. Problem występuje przy aktywnym ruchu RX i następującym po nim rozłączeniu urządzenia.

W jądrze Linux transport fuse-io-uring kopiuje req->in.h i req->out.h bezpośrednio do/z przestrzeni użytkownika w fuse_uring_copy_to_ring() i fuse_uring_commit(). Nagłówki znajdują się w obiekcie slab fuse_request, którego cache nie ma białej listy usercopy, co narusza CONFIG_HARDENED_USERCOPY i powoduje panikę jądra.

W jądrze Linux w sterowniku kryptograficznym iaa występuje błąd podczas dekompresji sprzętowej. Gdy wystąpi błąd analityki sprzętowej, ścieżka dekompresji przechodzi do fallbacku programowego, który zapisuje do req->dst, podczas gdy bufor jest nadal zmapowany jako DMA_FROM_DEVICE. Przy aktywnym SWIOTLB późniejsze dma_unmap_sg() kopiuje nieaktualny bufor pośredniczący nad req->dst, uszkadzając wynik.

W jądrze Linux w sterowniku wifi mwifiex występuje podatność polegająca na tym, że przy przerwanym oczekiwaniu na synchroniczne polecenie bufor danych przekazany przez wywołującego (często na stosie) nie jest odłączany od wciąż aktywnego polecenia firmware. Późna odpowiedź firmware może wtedy zapisać dane pod nieaktualnym adresem stosu, powodując uszkodzenie stosu jądra i panikę systemu.

W jądrze Linux w sterowniku wifi rtlwifi (rtl8192du) funkcja rtl92du_tx_fill_desc() używa wartości QoS TID z nagłówka 802.11 jako indeksu tablicy sta_entry->tids[]. Ponieważ ieee80211_get_tid() zwraca wartość 0..15, a tablica ma tylko MAX_TID_COUNT (9) elementów, TID większy niż 8 powoduje dostęp poza zakresem tablicy stanu agregacji.

W jądrze Linux w sterowniku wifi rtlwifi (rtl8192du) funkcja rtl92du_init_sw_vars() nie zwalnia pamięci przydzielonej w rtl92du_init_shared_data() w żadnej ze ścieżek błędów występujących po tym przydziale. Prowadzi to do wycieku pamięci.

W jądrze Linux w sterowniku wifi rtw88 funkcja rtw_txq_push_skb() nie zwalnia skb przed powrotem w ścieżce błędu, mimo że funkcja rtw_hci_tx_write() oczekuje zwolnienia skb w przypadku niepowodzenia. Prowadzi to do wycieku pamięci w rtw_txq_push().

W jądrze Linux w sterowniku wifi rtw88 (PCI) funkcja rtw_pci_probe() przydziela zasoby PCI przez rtw_pci_setup_resource() przed konfiguracją NAPI. Jeśli rtw_pci_napi_init() zawiedzie, ścieżka błędu pomija rtw_pci_destroy(), pozostawiając przydzielone zasoby PCI.

W jądrze Linux w sterowniku WiFi rtw89 (część PCI) brakowało callbacku .shutdown, który zatrzymywałby odpytywanie rfkill podczas restartu systemu. W wyniku tego na platformach arm64 dochodziło do paniki jądra z powodu asynchronicznego przerwania SError, gdy sterownik wykonywał odczyt MMIO po zniszczeniu łącza PCIe. Dodano funkcję rtw89_pci_shutdown() ustawiającą flagę RTW89_FLAG_SHUTDOWN, która powoduje wczesne zakończenie rtw89_ops_rfkill_poll().

W jądrze Linux w sterowniku wifi mt76 (mt7615) funkcja mt7615_suspend() pozyskuje muteks mt76, a następnie wywołuje cancel_delayed_work_sync() na mac_work. Ponieważ mt7615_mac_work() również pozyskuje ten sam muteks, jeśli mac_work już działa i czeka na muteks, ścieżka suspend zakleszcza się.

W jądrze Linux w sterowniku wifi mt76 (mt7915) funkcja mt7915_mcu_get_eeprom() kopiuje stały blok EFUSE do bufora dev->mt76.eeprom.data pod adresem raportowanym przez MCU (res->addr) bez sprawdzenia go względem rozmiaru bufora. Złośliwe lub wadliwe urządzenie może zgłosić dowolny adres i wywołać 16-bajtowy zapis poza zakresem bufora.

W jądrze Linux w sterowniku wifi mt76 (mt7925) funkcja mlo_pm_work jest kolejkowna z 5-sekundowym opóźnieniem podczas konfiguracji oszczędzania energii multi-link i nigdy nie jest anulowana na ścieżce zatrzymania. Jeśli urządzenie zostanie zniszczone w tym oknie, praca przeżywa teardown, a jej timer odpala się później, próbując kolejkować do już nieistniejącej kolejki roboczej.

W jądrze Linux w funkcji mt7996_mcu_get_eeprom() sterownika wifi mt76 (układ mt7996) adres docelowy kopii bloku EFUSE/EXT jest wyliczany na podstawie adresu raportowanego przez MCU (event->addr), a ograniczana jest jedynie długość kopii, nigdy przesunięcie docelowe w buforze eeprom.data. Złośliwe lub wadliwe urządzenie może zgłosić dowolny adres i wymusić zapis poza zakresem bufora eeprom.data o rozmiarze do MT7996_EXT_EEPROM_BLOCK_SIZE bajtów.

W jądrze Linux sterowniki mt7996/mt7992 przekazują firmware'owi HW MAC-TXP dla ramek AddBA req, ale są urządzeniami FW-TXP. Przy zwalnianiu TX funkcja mt76_connac_txp_skb_unmap() błędnie dekoduje txp jako strukturę mt76_connac_fw_txp, przez co pętla unmap wykonuje się zero razy i mapowanie DMA skb w buf[1] nigdy nie jest zwalniane. Każda ramka AddBA req powoduje wyciek jednego mapowania TX DMA, co przy ciągłym ponownym łączeniu klientów wyczerpuje pulę swiotlb WED po około 1-2 dniach.

W jądrze Linux domyślny firmware EEPROM jest parsowany i kopiowany jako pełny EEPROM bez sprawdzenia jego długości. Obcięty plik może spowodować odczyt poza buforem firmware podczas walidacji wariantu lub kopii zapasowej.