CVE-2026-63992

What it actually does

This flaw is an out-of-bounds memory access in the Linux kernel tunnel packet-handling path. When iptunnel_pmtud_check_icmp() processes certain IPv4 ICMP path-MTU-discovery-related packets, it can assume the socket buffer transport header is initialized when it is not. In that state, the transport_header value may effectively point far outside the valid packet buffer, causing the kernel to read memory outside the intended skb data area. Depending on kernel build, memory layout, and traffic path, exploitation may result in kernel memory disclosure and/or a kernel crash or denial of service. The issue is remotely reachable over the network where affected kernel tunnel handling is exposed, requires no authentication, and does not require user interaction.

Why it matters to the business

Systems using vulnerable Linux kernels, especially those terminating or processing IP tunnel traffic, may be exposed to remote crashes or sensitive kernel memory disclosure from crafted network traffic. Operationally, this can affect VPNs, overlay networks, container networking, cloud networking nodes, routers, gateways, and hosts that rely on tunneling features. Although the vulnerability has a high CVSS score, it is not currently listed in CISA KEV, is not known to be used in ransomware campaigns, has low EPSS, and has no reported public exploit maturity in the provided data; remediation should still be prioritized for internet-facing or network-edge Linux systems and tunnel infrastructure.

How an attack unfolds

An attacker identifies a reachable Linux system that processes IPv4 tunnel-related traffic and sends specially formed ICMP packets associated with path MTU discovery. The vulnerable kernel code path may call iptunnel_pmtud_check_icmp() before the skb transport header has been set. Because the function uses that unset transport-header value, the kernel can reference memory outside the valid packet buffer. A successful attack may crash the kernel or expose kernel memory contents, depending on how the out-of-bounds access behaves on the target kernel and configuration. Exploitation is most plausible against systems where tunnel endpoints, overlay networking, or routing paths process untrusted ICMP traffic.

How to fix it

Upgrade affected Linux kernels to a version that includes the upstream fix for iptunnel_pmtud_check_icmp() so that the ICMP header is accessed relative to the IPv4 network header only after validating that the ICMP type is present in the skb linear data. No exact fixed package versions were provided in the input, so use the fixed kernel version from the relevant Linux distribution, appliance vendor, cloud image provider, or kernel maintainership channel. Where immediate patching is not possible, reduce exposure by limiting untrusted ICMP traffic to tunnel endpoints where operationally safe, restricting access to tunnel interfaces and routing gateways, applying network-edge filtering for unexpected encapsulation and PMTUD traffic, and prioritizing kernel hardening and reboot windows for exposed systems. Avoid disabling all ICMP indiscriminately without testing, because path MTU discovery may be required for reliable network operation.

How to confirm the fix worked

Confirm remediation by verifying that the running kernel package includes the vendor fix for this vulnerability, not just that an updated package is installed on disk. Validate with commands such as uname -a and distribution package queries, then compare the running kernel build to vendor advisories or changelogs referencing the tunnel PMTUD ICMP fix. Confirm that patched systems have been rebooted into the fixed kernel. For exposure validation, inventory Linux systems that use IP tunnels, VPNs, overlays, GRE/IPIP/SIT-like tunneling, container network overlays, or routing/gateway roles, and verify whether untrusted ICMP traffic can reach those systems. In staging, regression-test tunnel and PMTUD behavior after patching to ensure network paths continue to pass expected traffic.

Typical attack path

1. Identify Linux systems that process IP tunnel, overlay, VPN, routing, or encapsulated traffic.
2. Confirm that IPv4 ICMP path-MTU-discovery traffic can reach the vulnerable packet-processing path.
3. Send crafted ICMP traffic designed to trigger tunnel PMTUD handling when the skb transport header is unset.
4. Cause the vulnerable kernel routine to access memory outside the valid packet buffer.
5. Observe resulting impact, such as kernel instability, host reboot, network-service disruption, or potential memory disclosure.

How to detect it

Historical exploitation may be difficult to prove because the vulnerability is in kernel packet parsing and may not generate application-level logs. Review kernel logs, system journals, crash dumps, network device telemetry, and packet captures around unexplained reboots, kernel panics, tunnel outages, or spikes in ICMP traffic. Useful log sources include journalctl, /var/log/kern.log, /var/log/messages, /var/log/syslog, kdump/vmcore records, hypervisor reset events, network IDS/flow logs, firewall logs, and router or load-balancer telemetry in front of Linux tunnel endpoints. Look for kernel oops or panic messages occurring near tunnel or ICMP processing, unusual inbound ICMP fragmentation-needed or destination-unreachable traffic, malformed ICMP packets, repeated PMTUD-related probes, and host crashes without corresponding application errors. If packet captures are available, review ICMP traffic to systems acting as tunnel endpoints, especially bursts of unusual IPv4 ICMP packets immediately before instability. No named threat actors or campaigns were provided for this vulnerability.

• iptunnel_pmtud_check_icmp
• transport header
• skb->transport_header
• BUG: kernel NULL pointer dereference
• BUG: unable to handle kernel paging request
• general protection fault
• kernel panic
• Oops:
• Call Trace:
• icmp
• Frag needed
• fragmentation needed
• Destination Unreachable
• Path MTU
• PMTUD
• /var/log/kern.log
• /var/log/messages
• /var/log/syslog
• /proc/vmcore
• vmcore
• kdump

What your security team should do

• Prioritize patching internet-facing Linux tunnel endpoints, VPN gateways, routers, cloud network nodes, container networking hosts, and systems that process untrusted encapsulated traffic.
• Track vendor kernel advisories and apply the distribution-specific fixed kernel package as soon as available; ensure systems are rebooted into the fixed kernel.
• Inventory use of Linux tunneling and overlay networking features across servers, appliances, Kubernetes/container nodes, virtual network gateways, and cloud images.
• Temporarily restrict unsolicited or unexpected ICMP traffic to tunnel-processing systems where this can be done without breaking path MTU discovery or production connectivity.
• Increase monitoring for kernel oops, panic, unexpected reboot, tunnel interface instability, and abnormal ICMP traffic volume targeting network-edge Linux systems.
• Because there is no KEV listing, no known ransomware use, low EPSS, and no public exploit maturity in the provided data, handle as high-severity preventive remediation rather than confirmed active exploitation unless local telemetry indicates otherwise.