CVE-2026-93805

W jądrze Linuksa usunięto następującą lukę:

Wi-Fi: cfg80211: sprawdź długość ramek wywołania zwrotnego rx/tx MLME przed dostępem

cfg80211_rx_mlme_mgmt() i cfg80211_tx_mlme_mgmt() wywołują punkty śledzenia
przed odrzuceniem ramek krótszych niż pole sterowania ramką. po
że wymagają tylko len >= 2 przed wysłaniem do podtypu
procedury obsługi, które zakładają, że ich stałe pola są obecne.

Ramki, które to powodują, nie są krótsze niż 2 bajty; są krótkie
w stosunku do ich podtypu. mwifiex to konkretny przykład w drzewie na
długość boku: mwifiex_process_mgmt_packet() wymaga tylko 4-adresu
ieee80211_hdr plus 2-bajtowy prefiks długości oprogramowania sprzętowego przed przekazaniem pliku
ramkę do cfg80211_rx_mlme_mgmt(). Po usunięciu przedrostka długości i
usunięcie adresu4, pkt_len może wynosić dokładnie 24: zarządzanie samymi 3 adresami
nagłówek bez treści kodu przyczyny. Istniejący WARN_ON(len <2) nie
uruchom taką ramkę, a następnie cfg80211_process_deauth() odczytuje
u.deauth.reason_code jako dwubajtowy dostęp rozpoczynający się od offsetu 24,
bezpośrednio za 24-bajtowym buforem.

Dodaj bramkę długości sterującej ramką, a następnie sprawdź minimum każdego podtypu
rozmiar ramki w łańcuchu if/else-if, który odzwierciedla logikę wysyłania. Ślad
dopiero po stwierdzeniu, że rama jest dobrze uformowana.

Skutki uboczne tej zmiany:
- Wartość WARN_ON(len < 2) została usunięta. Chronił tylko kontrolę ramki
czytaj, nigdy podtyp nie ma stałych pól i nie uruchamia się na
ramki, które faktycznie wyzwalają odczyt przekroczenia zakresu (które wynoszą >= 2).
Kontrola len >= 2 jest zachowywana jako ochrona przed wyłuskaniem
Frame_control, ale bez ostrzeżenia: są to wyeksportowane wywołania zwrotne
a zniekształconą ramkę ze sterownika należy raczej wyrzucić po cichu
niż odwrócony.
- cfg80211_tx_mlme_mgmt() poprzednio kierował każdy podtyp inny niż deauth
poprzez obsługę dysocjacji; teraz po cichu ignoruje nierozpoznane
podtypy.