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

> A remote attacker can crash the Linux kernel via oversized Wi-Fi fragments causing an integer overflow in mac80211.

- **Severity:** Not scored
- **Exploited in the wild:** Not known
- **Login needed:** Not needed
- **Attackable:** Local or same network only
- **Victim action needed:** Not needed
- **Fix available:** Yes
- **Published:** 18 Oct 2026
- **Updated:** 19 Oct 2026
- **Also known as:** AZL-109343, BELL-CVE-2026-98829, DEBIAN-CVE-2026-98829, GHSA-8w97-qwf2-rgh5, UBUNTU-CVE-2026-98829

## What is CVE-2026-98829?

CVE-2026-98829 is a vulnerability in Linux, published on 18 Oct 2026. It can only be exploited from the same machine or local network, with no action from the victim.

### Official description

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]

## Which versions are affected by CVE-2026-98829?


## How do I fix CVE-2026-98829?

Apply the vendor's patch.

## Is CVE-2026-98829 being exploited?

There is no known exploitation of CVE-2026-98829 in the wild and no public exploit code.

## Fix prompt for AI coding agents

```text
Check this codebase for CVE-2026-98829 and fix it if it is affected.

What it is: CVE-2026-98829 is a vulnerability in Linux, published on 18 Oct 2026. It can only be exploited from the same machine or local network, with no action from the victim.
Exploitation: There is no known exploitation of CVE-2026-98829 in the wild and no public exploit code.

Affected product: Linux. No package-level version data is available, so check the vendor advisory linked from the reference page.

Task:
1. Search the dependency manifests and lockfiles (for example package.json, package-lock.json, requirements.txt, poetry.lock, uv.lock, pom.xml, build.gradle, go.mod, Cargo.lock, Gemfile.lock) and any Dockerfiles for the affected packages, including transitive dependencies.
2. If an affected version is in use, upgrade it to the fixed version for its release line with the project's package manager, so the lockfile is regenerated. Prefer the smallest upgrade that fixes it.
3. If there is no fix, or the upgrade would break the build, do not guess: explain the risk and the safest workaround instead.
4. Run the tests and summarise what changed and why.
5. If nothing in the project is affected, say so and change nothing.

Reference: https://insights.sbomify.com/CVE-2026-98829/ (Markdown: https://insights.sbomify.com/CVE-2026-98829/index.md)
```

## Sources

- CVE record: https://www.cve.org/CVERecord?id=CVE-2026-98829
- NVD: https://nvd.nist.gov/vuln/detail/CVE-2026-98829
- OSV: https://osv.dev/vulnerability/CVE-2026-98829

---
From sbomify Insights: https://insights.sbomify.com/CVE-2026-98829/
Summaries are generated and may contain mistakes; the official description above is the record.