CVE-2026-98829
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:
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:
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.
Read full descriptionShow less
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]
Technical details traces, logs and code from the original report
entry->extra_len += rx->skb->len;
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);
}CVSS
NVD hasn't assigned a CVSS score to this CVE (common since the April 2026 policy change).
Exploitation probability (EPSS)
- Probability of exploitation in the next 30 days
- 0.17 %
- Percentile among all scored CVEs
- 5
- Score date
- 10/20/2026
EPSS (Exploit Prediction Scoring System, FIRST) estimates how likely a vulnerability is to be exploited in the wild within 30 days. It complements CVSS (impact) and CISA KEV (confirmed exploitation).
Affected technologies (1)
⚠ AI-inferred from the description — NVD hasn't analyzed this CVE yet, these aren't verified CPEs.
References
Raw JSON (NVD)
Show
{
"id": "CVE-2026-98829",
"cveTags": [],
"metrics": {},
"affected": [
{
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"affectedData": [
{
"repo": "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git",
"vendor": "Linux",
"product": "Linux",
"versions": [
{
"status": "affected",
"version": "69f132236827ce7d4531846cc2b9447dd5620aff",
"lessThan": "9338b2dea74cb0fc80a4c958b68e687610ba2261",
"versionType": "git"
},
{
"status": "affected",
"version": "69f132236827ce7d4531846cc2b9447dd5620aff",
"lessThan": "870b8cb9baa9bd859deceb33ae158011e6ba2360",
"versionType": "git"
},
{
"status": "affected",
"version": "69f132236827ce7d4531846cc2b9447dd5620aff",
"lessThan": "5e4f3509793b4db2c0835340224743db680e861f",
"versionType": "git"
}
],
"programFiles": [
"net/mac80211/drop.h",
"net/mac80211/rx.c"
],
"defaultStatus": "unaffected"
},
{
"repo": "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git",
"vendor": "Linux",
"product": "Linux",
"versions": [
{
"status": "affected",
"version": "4.3"
},
{
"status": "unaffected",
"version": "0",
"lessThan": "4.3",
"versionType": "semver"
},
{
"status": "unaffected",
"version": "6.18.56",
"versionType": "semver",
"lessThanOrEqual": "6.18.*"
},
{
"status": "unaffected",
"version": "7.2.10",
"versionType": "semver",
"lessThanOrEqual": "7.2.*"
},
{
"status": "unaffected",
"version": "7.3",
"versionType": "original_commit_for_fix",
"lessThanOrEqual": "*"
}
],
"programFiles": [
"net/mac80211/drop.h",
"net/mac80211/rx.c"
],
"defaultStatus": "affected"
}
]
}
],
"published": "2026-10-18T16:17:37.140",
"references": [
{
"url": "https://git.kernel.org/stable/c/5e4f3509793b4db2c0835340224743db680e861f",
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67"
},
{
"url": "https://git.kernel.org/stable/c/870b8cb9baa9bd859deceb33ae158011e6ba2360",
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67"
},
{
"url": "https://git.kernel.org/stable/c/9338b2dea74cb0fc80a4c958b68e687610ba2261",
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67"
}
],
"vulnStatus": "Received",
"descriptions": [
{
"lang": "en",
"value": "In the Linux kernel, the following vulnerability has been resolved:\n\nwifi: mac80211: drop oversized fragments to avoid extra_len overflow\n\nIn ieee80211_rx_h_defragment(), fragment payloads are accumulated into\nentry->extra_len as subsequent fragments arrive:\n\n entry->extra_len += rx->skb->len;\n\nWhen the final fragment arrives, the head fragment is dequeued, and\npskb_expand_head() is called with entry->extra_len to ensure sufficient\ntailroom for all queued fragments before copying:\n\n if (skb_tailroom(rx->skb) < entry->extra_len) {\n if (unlikely(pskb_expand_head(rx->skb, 0, entry->extra_len,\n GFP_ATOMIC))) {\n ...\n }\n }\n while ((skb = __skb_dequeue(&entry->skb_list))) {\n skb_put_data(rx->skb, skb->data, skb->len);\n dev_kfree_skb(skb);\n }\n\nIn commit 69f132236827 (\"mac80211: shrink struct\nieee80211_fragment_entry\"), entry->extra_len was narrowed from unsigned\nint to u16 in order to reduce structure memory footprint.\n\nHowever, an IEEE 802.11 frame sequence can contain up to 16 fragments\n(frag numbers 0..15). If a sequence of large fragments arrives (e.g. from\na malicious peer or rogue AP), the sum of fragment lengths can exceed\n65535 bytes (for example, 15 fragments of 4400 bytes total 66000 bytes).\nBecause extra_len is a u16, this addition overflows and wraps around\nmodulo 65536 (e.g. 66000 wraps to 464).\n\nConsequently, pskb_expand_head() allocates only the truncated amount of\ntailroom (or is skipped entirely if the head fragment already has >= 464\nbytes of tailroom). When skb_put_data() subsequently iterates through the\nqueued skb list, it appends the full payload into the undersized buffer,\ncausing skb_put() to trigger skb_over_panic() and crash the kernel in\nsoftirq context.\n\nA legitimate MSDU in IEEE 802.11 is at most 2304 bytes (or up to 7935/11454\nbytes for A-MSDU, which is not fragmented), well below U16_MAX.\n\nFix this without increasing the size of struct ieee80211_fragment_entry by\nchecking whether adding the incoming fragment length would exceed U16_MAX.\nIf so, purge the queued fragments and drop the frame.\n\n[assign a separate drop reason]"
}
],
"lastModified": "2026-10-19T10:19:46.943",
"sourceIdentifier": "416baaa9-dc9f-4396-8d5f-8c081fb06d67"
}