CVE-2026-63994

What it actually does

This vulnerability is a use-after-free condition in the Linux kernel tunnel path MTU discovery code. The affected functions cache IPv4 or IPv6 network-header pointers before calling skb_cow(), a routine that may reallocate the packet buffer backing memory. If the buffer is reallocated, the cached header pointer can reference freed memory and later be dereferenced while building ICMP or ICMPv6 path-MTU messages for tunneled traffic. In the worst case, a remote unauthenticated attacker able to send traffic that exercises affected tunnel PMTU handling could trigger kernel memory corruption, causing denial of service and potentially enabling code execution in kernel context.

Why it matters to the business

Successful exploitation could crash affected Linux systems or network appliances, interrupting services that rely on tunneling, overlay networking, VPNs, container networking, or routing functions. Because the flaw is in kernel networking code and has a network-reachable CVSS profile, exposed infrastructure should be treated as high priority even though no public exploitation or CISA KEV listing is currently known. Systems acting as tunnel endpoints, gateways, Kubernetes/container hosts, VPN concentrators, routers, or cloud networking nodes are likely to carry higher operational risk than general-purpose hosts.

How an attack unfolds

An attacker first identifies a Linux system that processes tunneled IP traffic and can be induced to generate path-MTU-related ICMP or ICMPv6 responses. The attacker then sends crafted network traffic through or toward the tunnel endpoint so that the kernel enters the iptunnel_pmtud_build_icmp() or iptunnel_pmtud_build_icmpv6() path. During handling, the kernel may call skb_cow(), which can reallocate the packet buffer, while previously cached IPv4 or IPv6 header pointers still reference the old buffer. Subsequent use of those stale pointers can corrupt kernel memory or trigger a kernel fault. Reliable exploitation for code execution would require shaping heap state and overcoming kernel hardening, but denial of service through kernel panic or networking subsystem instability is the most plausible immediate outcome.

How to fix it

Apply the Linux kernel update containing the upstream fix that reloads network-header pointers after skb_cow() in iptunnel_pmtud_build_icmp() and iptunnel_pmtud_build_icmpv6(). Because no product-specific fixed versions were provided, use the security advisory and patched kernel packages from the relevant Linux distribution, appliance vendor, cloud image provider, or embedded platform maintainer. Prioritize systems that terminate or forward tunneled traffic, including IP-in-IP, GRE, SIT, VXLAN/Geneve-based overlays where applicable, VPN gateways, Kubernetes/container nodes, routers, and network appliances. If immediate patching is not possible, reduce exposure by limiting who can send traffic to tunnel endpoints, filtering unnecessary tunnel protocols at network boundaries, disabling unused tunnel interfaces, applying anti-spoofing controls, and monitoring for kernel crashes or unusual ICMP/ICMPv6 PMTU activity. Reboot into the patched kernel after installation; merely installing kernel packages is not sufficient if the running kernel is still vulnerable.

How to confirm the fix worked

Confirm remediation by verifying that the running kernel, not only the installed package, is at a vendor-fixed version. Use distribution-specific tooling such as uname -r, package manager advisory checks, livepatch status, and vulnerability scanner results to confirm the active kernel includes the fix. Validate exposure by inventorying hosts with configured tunnel interfaces and hosts that process encapsulated traffic. Review loaded modules, network interface types, routing configuration, and firewall rules to identify systems reachable as tunnel endpoints. Where feasible, perform controlled regression testing of tunnel PMTU behavior after patching to ensure ICMP and ICMPv6 fragmentation-needed messages are generated without kernel warnings, oopses, or packet loss.

Typical attack path

1. Identify Linux systems exposed as tunnel endpoints, overlay-network nodes, VPN gateways, routers, or container networking hosts.
2. Send traffic that causes tunnel path MTU discovery processing and ICMP or ICMPv6 packet generation.
3. Trigger the vulnerable code path where skb_cow() reallocates the packet buffer after network-header pointers were cached.
4. Cause the kernel to dereference stale header pointers, resulting in memory corruption or a kernel crash.
5. Optionally repeat traffic to create sustained denial of service against affected network services or hosts.

How to detect it

Look for signs that the kernel entered the vulnerable tunnel PMTU code path and then faulted or behaved abnormally. Useful sources include kernel logs, system journals, crash dumps, hypervisor reset events, appliance watchdog logs, netconsole output, panic/oops records, and network telemetry around tunnel endpoints. Search for kernel oops or panic messages referencing iptunnel_pmtud_build_icmp, iptunnel_pmtud_build_icmpv6, skb_cow, use-after-free, KASAN, slab corruption, general protection faults, page faults, or NULL/invalid pointer dereferences near tunnel or ICMP/ICMPv6 processing. Correlate crashes with bursts of encapsulated traffic, unusual fragmentation-needed or packet-too-big messages, abnormal PMTU discovery behavior, repeated tunnel interface resets, or traffic from untrusted sources to tunnel endpoints. Because exploitation may leave no durable file artifact, absence of filesystem indicators does not rule out attempted exploitation; memory crash dumps and packet captures are the highest-value evidence.

• iptunnel_pmtud_build_icmp
• iptunnel_pmtud_build_icmpv6
• skb_cow
• BUG: KASAN: use-after-free
• KASAN: use-after-free
• general protection fault
• BUG: kernel NULL pointer dereference
• Unable to handle kernel paging request
• kernel panic
• Oops:
• ICMP Fragmentation Needed
• ICMPv6 Packet Too Big
• NETDEV WATCHDOG
• skb_over_panic
• skb_under_panic

What your security team should do

• Prioritize patching internet-facing or untrusted-network-facing Linux tunnel endpoints, VPN gateways, routers, container hosts, and overlay-network nodes.
• Verify that systems have rebooted into the fixed kernel or are protected by a vendor-supported live patch that specifically covers this flaw.
• Inventory tunnel interfaces and encapsulation protocols across Linux infrastructure to identify high-risk exposure.
• Restrict access to tunnel endpoints and block unused encapsulation protocols at perimeter and internal segmentation points.
• Increase monitoring for kernel oops, panic, KASAN, slab, skb, ICMP, ICMPv6, and tunnel-related errors until patching is complete.
• Treat repeated unexplained crashes of network-facing Linux tunnel systems as potentially suspicious and preserve logs, crash dumps, and packet captures for investigation.
• Track vendor advisories for exact fixed kernel versions because downstream distributions may backport the fix without changing to an obvious upstream kernel version.