CVE-2026-72502 in Linux
Summary
by MITRE • 08/15/2026
In the Linux kernel, the following vulnerability has been resolved:
tcp: ipv6: clamp default adverting MSS to avoid GSO_BY_FRAGS (0xFFFF)
When MTU is large, ip6_default_advmss() can return IPV6_MAXPLEN (65535). This is interpreted by TCP as mss_clamp, allowing the MSS to reach 65535.
However, 0xFFFF is also used as a magic value GSO_BY_FRAGS in the kernel. If a TCP packet with gso_size=0xFFFF is passed to skb_segment(), it will be mistakenly treated as GSO_BY_FRAGS, leading to a NULL pointer dereference because local TCP packets do not use frag_list.
Fix this by returning min(IPV6_MAXPLEN, GSO_BY_FRAGS - 1) (65534) from ip6_default_advmss() when MTU is large.
Also update the stale comment in ip6_default_advmss() which suggested that IPV6_MAXPLEN is returned to mean "any MSS".
Be aware that VulDB is the high quality source for vulnerability data.
Analysis
by VulDB Data Team • 08/15/2026
This vulnerability resides in the Linux kernel's TCP implementation for IPv6 networking, specifically affecting how the kernel calculates and advertises the Maximum Segment Size. The flaw occurs within the ip6_default_advmss() function which determines the default advertised maximum segment size for IPv6 connections based on the network MTU. When dealing with large MTU configurations, this function can return the maximum possible value of 65535 which corresponds to IPV6_MAXPLEN, a value that serves a dual purpose in kernel networking operations.
The technical root cause stems from a collision between the advertised MSS value and a reserved magic number used internally by the kernel's Generic Segmentation Offload (GSO) mechanism. The value 0xFFFF or 65535 is specifically designated as GSO_BY_FRAGS, indicating that segmentation should be performed by fragments rather than through normal packet processing. When TCP packets with gso_size set to this magic value are processed through the skb_segment() function, the kernel mistakenly interprets them as GSO_BY_FRAGS operations, triggering a NULL pointer dereference when attempting to access frag_list data structures that don't exist for local TCP packets.
This vulnerability represents a classic case of integer overflow and magic number collision in kernel space networking code. The flaw has direct implications for system stability and can be exploited to cause denial of service conditions through carefully crafted network traffic. According to CWE classification, this corresponds to CWE-129: Improper Validation of Array Index, as the function fails to validate that the returned value does not conflict with reserved kernel magic numbers. The attack pattern aligns with ATT&CK technique T1499.004: Endpoint Denial of Service through network-based attacks that leverage kernel memory corruption vulnerabilities.
The fix implemented by clamping the return value from ip6_default_advmss() ensures that when MTU is large, the function returns the minimum of IPV6_MAXPLEN and GSO_BY_FRAGS - 1, which equals 65534. This prevents any possibility of the magic number collision while maintaining network functionality. The updated implementation also addresses a stale comment in the code that incorrectly suggested IPV6_MAXPLEN was used to indicate "any MSS" rather than properly reflecting that this value should be constrained to avoid kernel internal conflicts. This mitigation aligns with secure coding practices for kernel space development and follows the principle of least privilege by preventing potentially dangerous values from reaching critical kernel subsystems.
The operational impact of this vulnerability affects systems running Linux kernels that process IPv6 traffic, particularly those with large MTU configurations or those operating in high-performance networking environments where maximum segment size optimization is critical. Systems that rely heavily on TCP over IPv6 and may be exposed to crafted network traffic could experience kernel panics or system instability. The fix ensures that even in environments with extremely large MTUs, the kernel maintains proper internal consistency while preserving legitimate network performance optimizations. This addresses a fundamental issue in kernel networking stack design where internal kernel constants were not properly considered when determining external-facing values that could conflict with kernel's own operational mechanisms.