GHSA-M5WC-GF88-8H7M
Vulnerability from github – Published: 2026-10-14 15:32 – Updated: 2026-10-14 15:32In the Linux kernel, the following vulnerability has been resolved:
net: ipv4: Fix UDP length overflow with PMTU discover and big MTU
This commit bounds cork->base.fragsize to IP_MAX_MTU to avoid a possible overflow of UDP length that triggers a WARN in udp_set_len_short when setsockopt IP_MTU_DISCOVER is set to IP_PMTUDISC_PROBE, and a large packet is sent over a netdev with an unusually large MTU.
Steps to reproduce:
- Set device MTU bigger than IP_MAX_MTU + 20. cork->base.fragsize will be set to that MTU in ip_setup_cork.
- Set IP_MTU_DISCOVER to IP_PMTUDISC_PROBE. It lets maxnonfragsize be set to device MTU (cork->fragsize) in __ip_append_data, rather than to IP_MAX_MTU.
- Send 65528 bytes of payload (+8 bytes of UDP header, +20 bytes of IPv4 header). Device MTU allows it (it's only one byte bigger than IP_MAX_MTU + IPv4 header, and the device MTU is bigger than that).
- 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.
Note: IP_PMTUDISC_DO with IPv4 is safe, because ip_dst_mtu_maybe_forward always clamps at IP_MAX_MTU, unlike ip6_dst_mtu_maybe_forward.
The Fixes tag points at the first commit where I could reproduce the overflow with IPv4 and IP_PMTUDISC_PROBE.
{
"affected": [],
"aliases": [
"CVE-2026-98393"
],
"database_specific": {
"cwe_ids": [],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-10-14T14:17:50Z",
"severity": null
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\nnet: ipv4: Fix UDP length overflow with PMTU discover and big MTU\n\nThis commit bounds cork-\u003ebase.fragsize to IP_MAX_MTU to avoid a\npossible overflow of UDP length that triggers a WARN in\nudp_set_len_short when setsockopt IP_MTU_DISCOVER is set to\nIP_PMTUDISC_PROBE, and a large packet is sent over a netdev with an\nunusually large MTU.\n\nSteps to reproduce:\n\n1. Set device MTU bigger than IP_MAX_MTU + 20. cork-\u003ebase.fragsize will\n be set to that MTU in ip_setup_cork.\n2. Set IP_MTU_DISCOVER to IP_PMTUDISC_PROBE. It lets maxnonfragsize be\n set to device MTU (cork-\u003efragsize) in __ip_append_data, rather than\n to IP_MAX_MTU.\n3. Send 65528 bytes of payload (+8 bytes of UDP header, +20 bytes of\n IPv4 header). Device MTU allows it (it\u0027s only one byte bigger than\n IP_MAX_MTU + IPv4 header, 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\nNote: IP_PMTUDISC_DO with IPv4 is safe, because ip_dst_mtu_maybe_forward\nalways clamps at IP_MAX_MTU, unlike ip6_dst_mtu_maybe_forward.\n\nThe Fixes tag points at the first commit where I could reproduce the\noverflow with IPv4 and IP_PMTUDISC_PROBE.",
"id": "GHSA-m5wc-gf88-8h7m",
"modified": "2026-10-14T15:32:19Z",
"published": "2026-10-14T15:32:19Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-98393"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/81f540827d243b8dad76c1f44e70ea31719f393c"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/83fedc4741210f75be8ca5b487985a242bf6f18d"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/b83641e0ab8b20eefcc4cdc5a059f897375291a2"
}
],
"schema_version": "1.4.0",
"severity": []
}
Drag nodes to arrange them. Double-click a related vulnerability to open it, or a source to visit its link. The Physics button on the left tunes the layout and the simulation; the legend at the bottom left hides or shows nodes by kind and by sighting type.
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.
Vulnerability timeline
Sightings and recorded dates, grouped by day · UTC
Loading timeline…
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.
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.