CVE-2026-23130
ŚrednieCVSS 5.5Prawdopodobieństwo exploitacji (EPSS)
Niskie ryzykoPercentyl 0 - wyżej niż 0% wszystkich znanych CVE
Streszczenie
W jądrze Linux w sterowniku wifi ath12k występuje zakleszczenie (deadlock) podczas opróżniania kolejki ramek zarządzających. Po zmianie transmisji ramek zarządzających na wiphy work, wywołanie ath12k_mac_op_flush() z vif równym NULL blokuje wiphy lock, uniemożliwiając wykonanie oczekującej pracy transmisyjnej. Skutkuje to niepowodzeniem uwierzytelniania i asocjacji oraz komunikatem o nieudanym opróżnieniu kolejki transmisji mgmt.
Ocena ryzyka
Organizacje korzystające z kart Wi-Fi opartych na ath12k (np. WCN7850) mogą doświadczać niestabilnego połączenia Wi-Fi, nieudanych prób uwierzytelniania i asocjacji oraz zawieszeń w obsłudze ramek zarządzających. Może to prowadzić do utraty łączności sieciowej i przerw w działaniu usług.
Rekomendacja
Zaktualizuj jądro Linux do wersji zawierającej poprawkę dla CVE-2026-23130 (zmiana przenosząca wiphy_work_flush() przed sprawdzenie vif w ath12k_mac_op_flush()). Do czasu wdrożenia poprawki rozważ ograniczenie użycia dotkniętych kart Wi-Fi w krytycznych systemach.
Inne podatności w Linux kernel ath12k driver
Zobacz wszystkie- CVE-2025-38606Średnie
W jądrze Linux w sterowniku ath12k występuje błąd polegający na odwołaniu się do niezainicjalizowanego wskaźnika arvif->ar podczas obsługi utraty sygnału beacon. Problem dotyczy interfejsów P2P, które po zakończeniu skanowania mają odłączony obiekt radiowy, co prowadzi do dereferencji NULL i awarii jądra (KASAN: null-ptr-deref).
- CVE-2025-37743Średnie
W jądrze Linux w sterowniku wifi ath12k występuje wyciek pamięci podczas włączania rozszerzonego trybu statystyk. Sterownik alokuje obiekt mon_mpdu przy obsłudze TLV HAL_RX_MPDU_START, ale nie zwalnia go, gdy aktywny jest tylko rozszerzony tryb statystyk (bez trybu standalone monitor).
Oryginalny opis (angielski, źródło NVD)
In the Linux kernel, the following vulnerability has been resolved: wifi: ath12k: fix dead lock while flushing management frames Commit [1] converted the management transmission work item into a wiphy work. Since a wiphy work can only run under wiphy lock protection, a race condition happens in below scenario: 1. a management frame is queued for transmission. 2. ath12k_mac_op_flush() gets called to flush pending frames associated with the hardware (i.e, vif being NULL). Then in ath12k_mac_flush() the process waits for the transmission done. 3. Since wiphy lock has been taken by the flush process, the transmission work item has no chance to run, hence the dead lock. >From user view, this dead lock results in below issue: wlp8s0: authenticate with xxxxxx (local address=xxxxxx) wlp8s0: send auth to xxxxxx (try 1/3) wlp8s0: authenticate with xxxxxx (local address=xxxxxx) wlp8s0: send auth to xxxxxx (try 1/3) wlp8s0: authenticated wlp8s0: associate with xxxxxx (try 1/3) wlp8s0: aborting association with xxxxxx by local choice (Reason: 3=DEAUTH_LEAVING) ath12k_pci 0000:08:00.0: failed to flush mgmt transmit queue, mgmt pkts pending 1 The dead lock can be avoided by invoking wiphy_work_flush() to proactively run the queued work item. Note actually it is already present in ath12k_mac_op_flush(), however it does not protect the case where vif being NULL. Hence move it ahead to cover this case as well. Tested-on: WCN7850 hw2.0 PCI WLAN.HMT.1.1.c5-00302-QCAHMTSWPL_V1.0_V2.0_SILICONZ-1.115823.3
Dane podatności pochodzą z NVD (NIST) · CISA KEV · EPSS