FKIE_CVE-2026-97984
Vulnerability from fkie_nvd - Published: 2026-09-25 11:17 - Updated: 2026-09-25 11:17
Severity
Summary
In the Linux kernel, the following vulnerability has been resolved:
net: ipv6: Fix UDP length overflow with PMTU discover and big MTU
This commit bounds cork->base.fragsize to IP6_MAX_MTU for UDP sockets to
avoid a possible overflow of UDP length that triggers a WARN in
udp_set_len_short when setsockopt IPV6_MTU_DISCOVER is set to
IPV6_PMTUDISC_DO or IPV6_PMTUDISC_PROBE, and a large packet is sent over
a netdev with an unusually large MTU.
Steps to reproduce (included in the new selftest):
1. Set device MTU bigger than IP6_MAX_MTU. cork->base.fragsize will be
set to that MTU in ip6_setup_cork.
2. Set IPV6_MTU_DISCOVER to IPV6_PMTUDISC_PROBE or IPV6_PMTUDISC_DO. It
lets maxnonfragsize be set to device MTU (cork->fragsize) in
__ip6_append_data, rather than to IP6_MAX_MTU.
3. Send 65528 bytes of payload (+8 bytes of UDP header, +40 bytes of
IPv6 header). Device MTU allows it (it's only one byte bigger than
IP6_MAX_MTU, and the device MTU is bigger than that).
4. The UDP length in the built packet is 65536, which overflows the
16-bit length field and triggers the WARN in udp_set_len_short.
To avoid breaking sending UDP jumbograms over raw IPv6 sockets, limit
the change to UDP sockets only.
The original overflow bug with IPv6 and IPV6_PMTUDISC_DO seems to
predate git history (verified reproduction on 2.6.21), was fixed later,
and then reappeared in commit 427faee167bc ("net: ipv6: introduce
ip6_dst_mtu_maybe_forward"), which is chosen as the Fixes tag here. The
overflow with IPV6_PMTUDISC_PROBE reproduces since its introduction in
commit 628a5c561890 ("[INET]: Add IP(V6)_PMTUDISC_RPOBE").
References
Impacted products
| Vendor | Product | Version |
|---|
{
"affected": [
{
"affectedData": [
{
"defaultStatus": "unaffected",
"product": "Linux",
"programFiles": [
"net/ipv6/ip6_output.c"
],
"repo": "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git",
"vendor": "Linux",
"versions": [
{
"lessThan": "1d56a00ec91f2885c64ea5b8cea18cb746b91bbb",
"status": "affected",
"version": "427faee167bce4ccb0b22f6815a9ac509e31d4c3",
"versionType": "git"
},
{
"lessThan": "ce66352d3eb21825410af8b91db7cc4bb8e22c98",
"status": "affected",
"version": "427faee167bce4ccb0b22f6815a9ac509e31d4c3",
"versionType": "git"
},
{
"lessThan": "e01b7c176d9af2b7c22bb3fe12cf9a7904f99fdc",
"status": "affected",
"version": "427faee167bce4ccb0b22f6815a9ac509e31d4c3",
"versionType": "git"
},
{
"lessThan": "0ae10b6be49b425827659b23bcce498f80eb7182",
"status": "affected",
"version": "427faee167bce4ccb0b22f6815a9ac509e31d4c3",
"versionType": "git"
}
]
},
{
"defaultStatus": "affected",
"product": "Linux",
"programFiles": [
"net/ipv6/ip6_output.c"
],
"repo": "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git",
"vendor": "Linux",
"versions": [
{
"status": "affected",
"version": "5.15"
},
{
"lessThan": "5.15",
"status": "unaffected",
"version": "0",
"versionType": "semver"
},
{
"lessThanOrEqual": "6.12.*",
"status": "unaffected",
"version": "6.12.111",
"versionType": "semver"
},
{
"lessThanOrEqual": "6.18.*",
"status": "unaffected",
"version": "6.18.53",
"versionType": "semver"
},
{
"lessThanOrEqual": "7.2.*",
"status": "unaffected",
"version": "7.2.7",
"versionType": "semver"
},
{
"lessThanOrEqual": "*",
"status": "unaffected",
"version": "7.3-rc3",
"versionType": "original_commit_for_fix"
}
]
}
],
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67"
}
],
"cveTags": [],
"descriptions": [
{
"lang": "en",
"value": "In the Linux kernel, the following vulnerability has been resolved:\n\nnet: ipv6: Fix UDP length overflow with PMTU discover and big MTU\n\nThis commit bounds cork-\u003ebase.fragsize to IP6_MAX_MTU for UDP sockets to\navoid a possible overflow of UDP length that triggers a WARN in\nudp_set_len_short when setsockopt IPV6_MTU_DISCOVER is set to\nIPV6_PMTUDISC_DO or IPV6_PMTUDISC_PROBE, and a large packet is sent over\na netdev with an unusually large MTU.\n\nSteps to reproduce (included in the new selftest):\n\n1. Set device MTU bigger than IP6_MAX_MTU. cork-\u003ebase.fragsize will be\n set to that MTU in ip6_setup_cork.\n2. Set IPV6_MTU_DISCOVER to IPV6_PMTUDISC_PROBE or IPV6_PMTUDISC_DO. It\n lets maxnonfragsize be set to device MTU (cork-\u003efragsize) in\n __ip6_append_data, rather than to IP6_MAX_MTU.\n3. Send 65528 bytes of payload (+8 bytes of UDP header, +40 bytes of\n IPv6 header). Device MTU allows it (it\u0027s only one byte bigger than\n IP6_MAX_MTU, and the device MTU is bigger than that).\n4. The UDP length in the built packet is 65536, which overflows the\n 16-bit length field and triggers the WARN in udp_set_len_short.\n\nTo avoid breaking sending UDP jumbograms over raw IPv6 sockets, limit\nthe change to UDP sockets only.\n\nThe original overflow bug with IPv6 and IPV6_PMTUDISC_DO seems to\npredate git history (verified reproduction on 2.6.21), was fixed later,\nand then reappeared in commit 427faee167bc (\"net: ipv6: introduce\nip6_dst_mtu_maybe_forward\"), which is chosen as the Fixes tag here. The\noverflow with IPV6_PMTUDISC_PROBE reproduces since its introduction in\ncommit 628a5c561890 (\"[INET]: Add IP(V6)_PMTUDISC_RPOBE\")."
}
],
"id": "CVE-2026-97984",
"lastModified": "2026-09-25T11:17:26.443",
"metrics": {},
"published": "2026-09-25T11:17:26.443",
"references": [
{
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"url": "https://git.kernel.org/stable/c/0ae10b6be49b425827659b23bcce498f80eb7182"
},
{
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"url": "https://git.kernel.org/stable/c/1d56a00ec91f2885c64ea5b8cea18cb746b91bbb"
},
{
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"url": "https://git.kernel.org/stable/c/ce66352d3eb21825410af8b91db7cc4bb8e22c98"
},
{
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"url": "https://git.kernel.org/stable/c/e01b7c176d9af2b7c22bb3fe12cf9a7904f99fdc"
}
],
"sourceIdentifier": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"vulnStatus": "Received"
}
Loading…
Loading…
Experimental. This forecast is provided for visualization only and may change without notice. Do not use it for operational decisions.
Forecast uses a logistic model when the trend is rising, or an exponential decay model when the trend is falling. Fitted via linearized least squares.
Sightings
| Author | Source | Type | Date | Other |
|---|
Nomenclature
- Seen: The vulnerability was mentioned, discussed, or observed by the user.
- Confirmed: The vulnerability has been validated from an analyst's perspective.
- Published Proof of Concept: A public proof of concept is available for this vulnerability.
- Exploited: The vulnerability was observed as exploited by the user who reported the sighting.
- Patched: The vulnerability was observed as successfully patched by the user who reported the sighting.
- Not exploited: The vulnerability was not observed as exploited by the user who reported the sighting.
- Not confirmed: The user expressed doubt about the validity of the vulnerability.
- Not patched: The vulnerability was not observed as successfully patched by the user who reported the sighting.
Loading…
Loading…
The MITRE ATT&CK techniques below are AI-generated suggestions, inferred from the description of the
vulnerability by the CIRCL/vulnerability-attack-technique-classification-roberta-base
model, served locally by ML-Gateway.
They have not been verified by an analyst and are provided for guidance only.
The approach is described in our paper Mapping CVEs to MITRE ATT&CK Techniques: A Curated Gold-Set Classifier and the Limits of LLM-Assisted Label Expansion.
Browse all ATT&CK techniques and the vulnerabilities related to each.
The approach is described in our paper Mapping CVEs to MITRE ATT&CK Techniques: A Curated Gold-Set Classifier and the Limits of LLM-Assisted Label Expansion.
Browse all ATT&CK techniques and the vulnerabilities related to each.
Loading…
Related by attack behaviour
Vulnerabilities whose description is nearest to this one in the vector space of the CIRCL/vulnerability-attack-technique-biencoder model. This is a similarity search over the bi-encoder space (plain cosine), not a classification, and it has no measured accuracy.
Loading…