CVE-2026-98829
Low risk· EPSS 5%Exploitation Probability (EPSS)
Low risk5th percentile - higher than 5% of all known CVEs
Summary
In the Linux kernel, ieee80211_rx_h_defragment() accumulates fragment payload lengths into the u16 field extra_len. When the sum of fragment lengths exceeds 65535 bytes, the value wraps around modulo 65536, causing an undersized buffer allocation and triggering skb_over_panic() in softirq context, which crashes the kernel.
Risk Assessment
A malicious peer or rogue AP can send a sequence of large fragments, causing a kernel crash or hang (denial of service) on a device with a wireless network card handled by mac80211.
Recommendation
Update the Linux kernel to a version containing the fix that checks whether adding the incoming fragment length would exceed U16_MAX and, if so, purges queued fragments and drops the frame.
Other vulnerabilities in Linux kernel mac80211
See all- CVE-2026-23396Medium
In the Linux kernel, mesh_matches_local() in mac80211 unconditionally dereferences ie->mesh_config. When called from mesh_rx_csa_frame(), the parsed action-frame elements may lack a Mesh Configuration IE, leaving the pointer NULL and causing a kernel NULL pointer dereference. An adjacent attacker can exploit this by sending a crafted CSA action frame with a valid Mesh ID IE but without the Mesh Configuration IE.
- CVE-2026-23279Medium
In the Linux kernel, the mesh_rx_csa_frame() function in mac80211 dereferences elems->mesh_chansw_params_ie without a NULL check. When a received CSA action frame omits the Mesh Channel Switch Parameters IE (element ID 118), the pointer remains NULL, causing a kernel NULL pointer dereference and crash. The bug has been present since kernel v3.13 (2014).
Original NVD description (English source)
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]
Vulnerability data from NVD (NIST) · CISA KEV · EPSS

