CVE-2026-98829: wifi: mac80211: drop oversized fragments to avoid extra_len overflow

Published Oct 18, 2026
·
Updated

In the Linux kernel, the following vulnerability has been resolved:

wifi: mac80211: drop oversized fragments to avoid extralen overflow

In ieee80211rxhdefragment(), fragment payloads are accumulated into entry->extralen as subsequent fragments arrive:

entry->extralen += rx->skb->len;

When the final fragment arrives, the head fragment is dequeued, and pskbexpandhead() is called with entry->extralen to ensure sufficient tailroom for all queued fragments before copying:

if (skbtailroom(rx->skb) < entry->extralen) { if (unlikely(pskbexpandhead(rx->skb, 0, entry->extralen, GFPATOMIC))) { ... } } while ((skb = skbdequeue(&entry->skblist))) { skbputdata(rx->skb, skb->data, skb->len); devkfreeskb(skb); }

In commit 69f132236827 ("mac80211: shrink struct ieee80211fragmententry"), entry->extralen 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 extralen is a u16, this addition overflows and wraps around modulo 65536 (e.g. 66000 wraps to 464).

Consequently, pskbexpandhead() allocates only the truncated amount of tailroom (or is skipped entirely if the head fragment already has >= 464 bytes of tailroom). When skbputdata() subsequently iterates through the queued skb list, it appends the full payload into the undersized buffer, causing skbput() to trigger skboverpanic() 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 U16MAX.

Fix this without increasing the size of struct ieee80211fragmententry by checking whether adding the incoming fragment length would exceed U16MAX. If so, purge the queued fragments and drop the frame.

[assign a separate drop reason]

Affected Software

1 affected component
Linux Linux kernel

Remediation

Recommended actions to resolve this vulnerability, in priority order.

  1. Compensating control

    In ieee80211_rx_h_defragment(), check whether adding an incoming fragment length would make the accumulated fragment length exceed U16_MAX; if so, purge the queued fragments and drop the frame.

Event History

Oct 18, 2026
CVE Published
via MITRE·03:49 PM
Data Sourced
via MITRE·03:49 PM
Description
Data Sourced
via NVD·04:17 PM
Description

Contact

SecAlerts Pty Ltd.
132 Wickham Terrace
Fortitude Valley,
QLD 4006, Australia
info@secalerts.co
By using SecAlerts services, you agree to our services end-user license agreement. This website is safeguarded by reCAPTCHA and governed by the Google Privacy Policy and Terms of Service. All names, logos, and brands of products are owned by their respective owners, and any usage of these names, logos, and brands for identification purposes only does not imply endorsement. If you possess any content that requires removal, please get in touch with us.
© 2026 SecAlerts Pty Ltd.
ABN: 70 645 966 203, ACN: 645 966 203