CVE-2026-98829
NoneCVSS
—
EPSS
0.2%
Published
Oct 18, 2026
CISA due date
—
Cloudanix analysis
A bug in how Linux handles pieces of wireless network messages can cause the computer to crash when it receives specially crafted Wi-Fi traffic.
- Exploitation
- Remote Unauthenticated
- Attacker needs
- None
- Complexity
- Low
- Impact
- Denial Of Service
- Component
- OS kernel
- Class
- Buffer Overflow
- Remediation
- Patch
- Effort
- Medium
- Patch risk
- Low
What it actually does
Integer overflow in ieee80211_rx_h_defragment() causes u16 extra_len to wrap when accumulating up to 16 large 802.11 fragments, leading to undersized pskb_expand_head allocation followed by skb_put_data that triggers skb_over_panic and kernel crash in softirq context.
Why it matters to the business
Wireless Linux systems may experience sudden kernel crashes and reboots when receiving crafted or malicious Wi-Fi fragment sequences, resulting in loss of connectivity and potential denial of service for affected devices.
How an attack unfolds
An attacker within Wi-Fi range transmits a sequence of 802.11 fragments whose lengths sum above 65535 bytes; the receiver's mac80211 stack accumulates the lengths, overflows the u16 field, allocates insufficient buffer space, and panics when reassembling the fragments.
How to fix it
Upgrade to a Linux kernel containing the fix that checks for U16_MAX overflow before accumulation and drops oversized fragment sequences; apply the change from the referenced commit or later stable releases that include the drop-reason logic.
How to confirm the fix worked
Confirm the kernel source contains the added U16_MAX check and drop logic in ieee80211_rx_h_defragment(); test by sending a 16-fragment sequence totaling >65535 bytes and verify the frame is dropped without panic.
Typical attack path
- Attacker associates or sends frames to a target Linux system using mac80211
- Sends initial fragment followed by up to 15 additional large fragments
- Kernel performs repeated extra_len += skb->len additions that wrap modulo 65536
- pskb_expand_head allocates truncated tailroom or is skipped
- skb_put_data appends full payloads into undersized buffer and panics
How to detect it
Inspect kernel logs for skb_over_panic or softirq context crashes involving mac80211 or ieee80211_fragment_entry; review wireless packet captures for fragment sequences with high aggregate length.
What your security team should do
- Prioritize kernel updates for all systems using mac80211 wireless drivers
- Monitor upstream stable kernel releases for the published fix
- Consider disabling unnecessary Wi-Fi interfaces on servers until patched
The record
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]
Affected packages
| Ecosystem | Package | Introduced | Fixed |
|---|