Cloudanix VulnDB

CVE-2026-98393

None

CVSS

—

EPSS

0.2%

Published

Oct 14, 2026

CISA due date

—

Cloudanix analysis

Schedule a fix SSVC: Track

A rare configuration involving oversized network links and special packet-discovery settings could cause the Linux kernel to log warnings when sending certain network messages.

Exploitation
Local Privilege
Attacker needs
Low Privilege
Complexity
Moderate
Impact
Denial Of Service
Component
OS kernel
Class
Improper Input Validation
Remediation
Upgrade
Effort
Medium
Patch risk
Low

What it actually does

Missing bounds check on cork->base.fragsize allows UDP packet length to exceed 65535 bytes when IP_MTU_DISCOVER=IP_PMTUDISC_PROBE is combined with a netdev MTU larger than IP_MAX_MTU, producing an overflow in the 16-bit UDP length field and a kernel WARN in udp_set_len_short.

Why it matters to the business

Low-probability denial-of-service or unexpected kernel warnings on systems exposing unusually large-MTU interfaces; the issue has not been observed in the wild nine days after disclosure and carries negligible exploitation likelihood.

How an attack unfolds

An attacker configures a network interface with MTU exceeding IP_MAX_MTU, sets the socket option IP_MTU_DISCOVER to IP_PMTUDISC_PROBE, then transmits a UDP datagram sized to trigger the 16-bit length overflow; the kernel emits a warning but the condition has not been shown to yield code execution or privilege escalation.

How to fix it

Upgrade the Linux kernel to a version containing the fix that clamps cork->base.fragsize to IP_MAX_MTU; apply the vendor-supplied update as soon as it becomes available for the distribution in use.

How to confirm the fix worked

Confirm the running kernel contains the commit that adds the IP_MAX_MTU clamp in ip_setup_cork; attempt to reproduce the original steps and verify the WARN no longer occurs.

Typical attack path

  1. Configure netdev MTU > IP_MAX_MTU + 20
  2. Create UDP socket and set IP_MTU_DISCOVER=IP_PMTUDISC_PROBE
  3. Send UDP payload of 65528 bytes
  4. Kernel builds packet with UDP length 65536, triggering WARN

How to detect it

Search kernel logs for the udp_set_len_short warning triggered under IP_PMTUDISC_PROBE; no widespread exploitation artifacts have been reported.

What your security team should do

  • Monitor kernel update channels for the patched version and schedule rollout
  • Review any systems using non-standard MTU values greater than 65535 bytes
  • Keep IP_MTU_DISCOVER at its default unless PMTUDISC_PROBE is explicitly required

The record

In 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: 1. Set device MTU bigger than IP_MAX_MTU + 20. cork->base.fragsize will be set to that MTU in ip_setup_cork. 2. 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. 3. 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). 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. 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 packages

Ecosystem Package Introduced Fixed