CVE-2026-98829 in Linux
Summary
by MITRE • 10/18/2026
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]
Statistical analysis made it clear that VulDB provides the best quality for vulnerability data.
Analysis
by VulDB Data Team • 10/18/2026
The vulnerability identified in the Linux kernel's mac80211 subsystem represents a critical integer overflow issue within the IEEE 802.11 fragment reassembly logic. Specifically, the function ieee80211_rx_h_defragment() is responsible for accumulating incoming fragmented frames into a buffer structure before reconstructing the original data unit. In an effort to optimize memory usage, commit 69f132236827 narrowed the type of entry->extra_len from unsigned int to u16. This optimization inadvertently introduced a boundary condition where the accumulation of fragment lengths can exceed the maximum value representable by a sixteen-bit unsigned integer, which is sixty-five thousand five hundred thirty-five bytes. When this threshold is breached during the processing of subsequent fragments, the arithmetic operation entry->extra_len += rx->skb->len results in an overflow, causing the value to wrap around modulo 65536 and produce a significantly smaller number than intended.
This integer truncation leads directly to insufficient memory allocation for the reassembled packet buffer. The code subsequently calls pskb_expand_head() with this truncated extra_len value to ensure there is adequate tailroom in the socket buffer structure before copying data. Because the allocated space corresponds only to the wrapped-around small value rather than the true total size of the fragments, the resulting buffer is drastically undersized relative to the actual payload being processed. When the system attempts to append the queued fragment data into this insufficiently sized buffer using skb_put_data(), it triggers a kernel panic via skb_over_panic(). This crash occurs within softirq context, meaning that an attacker can trigger a denial of service condition remotely by sending specially crafted wireless frames without requiring any prior authentication or privileged access.
From a threat modeling perspective, this vulnerability aligns with CWE-190 Integer Overflow or Wraparound and is exploitable via the ATT&CK technique T1498 Network Denial of Service. The attack vector involves transmitting a sequence of large IEEE 802.11 fragments from a rogue access point or malicious peer device. While legitimate Maximum Service Data Units in standard IEEE 802.11 are typically capped at two thousand three hundred four bytes, and even A-MSDU frames do not undergo fragmentation in the same manner, an attacker can easily construct fragment sequences that exceed sixty-five kilobytes when aggregated. The lack of validation on the cumulative size allows these oversized payloads to bypass initial checks until they reach the reassembly stage where the overflow occurs.
The remediation strategy implemented addresses this flaw by introducing a pre-addition check before updating entry->extra_len. Instead of allowing the arithmetic operation to proceed unchecked, the code now verifies whether adding the length of the incoming fragment would cause extra_len to exceed U16_MAX. If such an addition is detected, the system purges any previously queued fragments associated with that sequence and drops the current frame entirely. This approach effectively neutralizes the overflow condition without requiring a structural change to ieee80211_fragment_entry or increasing its memory footprint. By rejecting malformed fragment sequences early in the processing pipeline, the kernel maintains stability against maliciously crafted wireless traffic while preserving the intended memory optimization benefits of the previous patch.