CVE-2026-98829
Niskie ryzyko· EPSS 5%Prawdopodobieństwo exploitacji (EPSS)
Niskie ryzykoPercentyl 5 - wyżej niż 5% wszystkich znanych CVE
Streszczenie
W jądrze Linux w funkcji ieee80211_rx_h_defragment() podatność wynika z przepełnienia pola extra_len typu u16 podczas sumowania długości fragmentów ramek IEEE 802.11. Gdy suma długości fragmentów przekracza 65535 bajtów, wartość zawija się modulo 65536, co prowadzi do zbyt małej alokacji bufora i wywołania skb_over_panic() w kontekście softirq, powodując awarię jądra.
Ocena ryzyka
Złośliwy peer lub fałszywy punkt dostępowy może wysłać sekwencję dużych fragmentów, doprowadzając do zawieszenia lub awarii jądra (odmowa usługi) na urządzeniu z bezprzewodową kartą sieciową obsługiwaną przez mac80211.
Rekomendacja
Zaktualizuj jądro Linux do wersji zawierającej poprawkę, która sprawdza, czy dodanie długości przychodzącego fragmentu przekroczy U16_MAX, a jeśli tak — usuwa zakolejkowane fragmenty i odrzuca ramkę.
Inne podatności w Linux kernel mac80211
Zobacz wszystkie- CVE-2026-23396Średnie
W jądrze Linux w funkcji mesh_matches_local() (moduł mac80211) występuje bezwarunkowe odwołanie do ie->mesh_config. Gdy funkcja jest wywoływana z mesh_rx_csa_frame() i odebrana ramka akcji nie zawiera elementu Mesh Configuration IE, wskaźnik jest NULL, co prowadzi do dereferencji NULL i awarii jądra. Sąsiedni atakujący może to wykorzystać, wysyłając spreparowaną ramkę CSA z poprawnym Mesh ID IE, ale bez Mesh Configuration IE.
- CVE-2026-23279Średnie
W jądrze Linux w funkcji mesh_rx_csa_frame() (moduł mac80211) występuje brak sprawdzenia NULL dla wskaźnika elems->mesh_chansw_params_ie. Gdy odbierana ramka akcji CSA nie zawiera elementu Mesh Channel Switch Parameters IE (ID 118), wskaźnik pozostaje NULL, co prowadzi do dereferencji NULL i awarii jądra (kernel panic). Podatność istnieje od wersji jądra v3.13 (2014).
Oryginalny opis (angielski, źródło NVD)
In the Linux kernel, the following vulnerability has been resolved: wifi: mac80211: drop oversized fragments to avoid extra_len overflow In ieee80211_rx_h_defragment(), fragment payloads are accumulated into entry->extra_len as subsequent fragments arrive: entry->extra_len += rx->skb->len; When the final fragment arrives, the head fragment is dequeued, and pskb_expand_head() is called with entry->extra_len to ensure sufficient tailroom for all queued fragments before copying: if (skb_tailroom(rx->skb) < entry->extra_len) { if (unlikely(pskb_expand_head(rx->skb, 0, entry->extra_len, GFP_ATOMIC))) { ... } } while ((skb = __skb_dequeue(&entry->skb_list))) { skb_put_data(rx->skb, skb->data, skb->len); dev_kfree_skb(skb); } In commit 69f132236827 ("mac80211: shrink struct ieee80211_fragment_entry"), entry->extra_len was narrowed from unsigned int to u16 in order to reduce structure memory footprint. However, an IEEE 802.11 frame sequence can contain up to 16 fragments (frag numbers 0..15). If a sequence of large fragments arrives (e.g. from a malicious peer or rogue AP), the sum of fragment lengths can exceed 65535 bytes (for example, 15 fragments of 4400 bytes total 66000 bytes). Because extra_len is a u16, this addition overflows and wraps around modulo 65536 (e.g. 66000 wraps to 464). Consequently, pskb_expand_head() allocates only the truncated amount of tailroom (or is skipped entirely if the head fragment already has >= 464 bytes of tailroom). When skb_put_data() subsequently iterates through the queued skb list, it appends the full payload into the undersized buffer, causing skb_put() to trigger skb_over_panic() and crash the kernel in softirq context. A legitimate MSDU in IEEE 802.11 is at most 2304 bytes (or up to 7935/11454 bytes for A-MSDU, which is not fragmented), well below U16_MAX. Fix this without increasing the size of struct ieee80211_fragment_entry by checking whether adding the incoming fragment length would exceed U16_MAX. If so, purge the queued fragments and drop the frame. [assign a separate drop reason]
Dane podatności pochodzą z NVD (NIST) · CISA KEV · EPSS

