HIGH Introduced in 4.3
mac80211 Fragment Overflow
CVE-2026-98829
CVSS:3.1/AV:A/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H
01Description
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]
02KernelScan AI Analysis
Risk summary
A malicious WiFi peer or rogue access point can send a sequence of oversized fragmented frames that trigger an integer overflow in the mac80211 defragmentation logic. This causes a heap buffer overflow when reassembling fragments, leading to kernel crash or potential code execution. Any device with WiFi enabled and an active station or AP interface is exposed to attackers within radio range.
Vulnerability analysis
The mac80211 WiFi subsystem reassembles fragmented 802.11 frames by accumulating fragment payload lengths into a 16-bit counter. A previous optimization narrowed this counter from 32 to 16 bits, but the accumulation logic was not updated to prevent overflow. An attacker within WiFi range can send up to 16 large fragments whose combined length exceeds 65,535 bytes, causing the counter to wrap around. The kernel then allocates insufficient buffer space for reassembly and copies the full payload into the undersized buffer, corrupting adjacent kernel heap memory. The fix adds a bounds check before each fragment is queued: if adding the fragment length would exceed the 16-bit maximum, the partial frame is discarded and the frame is dropped. This prevents the overflow without increasing the structure size. The vulnerability is reachable from any WiFi peer — no authentication, local account, or user interaction is required — making all WiFi-enabled devices with active interfaces susceptible to remote denial of service or potential privilege escalation.
Lifecycle
03Fix Versions
| Branch | Introduced | Fixed in | Patch commit |
|---|---|---|---|
| 6.18 | 4.3 | 6.18.56 | 9338b2dea74c |
| 7.2 | 4.3 | 7.2.10 | 870b8cb9baa9 |
| mainline | 4.3 | 7.3 | 5e4f3509793b |
04CIP Kernels
State of the newest release of each Civil Infrastructure Platform SLTS tree, from CIP's own fix records.
| CIP tree | State |
|---|---|
| cip/6.12 | Affected — no CIP fix yet (latest 6.12.112-cip33) |
| cip/6.1 | Affected — no CIP fix yet (latest 6.1.189-cip61) |
| cip/6.1-rt | Affected — no CIP fix yet (latest 6.1.189-cip61-rt32) |
| cip/5.10 | Affected — no CIP fix yet (latest 5.10.271-cip78) |
| cip/5.10-rt | Affected — no CIP fix yet (latest 5.10.268-cip77-rt34) |
| cip/4.19 | Affected — no CIP fix yet (latest 4.19.325-cip136) |
| cip/4.19-rt | Affected — no CIP fix yet (latest 4.19.325-cip136-rt50) |
| cip/4.4 | Affected — no CIP fix yet (latest 4.4.302-cip115) |
| cip/4.4-rt | Affected — no CIP fix yet (latest 4.4.302-cip115-rt63) |