CVE-2026-63993

What it actually does

This is a Linux kernel use-after-free flaw in VXLAN packet handling. During VXLAN encapsulation or forwarding, skb_tunnel_check_pmtu() may reallocate or change the packet buffer head, invalidating a previously cached IP header pointer. If the kernel later reuses that stale pointer, it can read from or write to freed memory. Depending on kernel configuration, memory layout, and exploit reliability, this can cause kernel memory corruption, denial of service through kernel panic, information disclosure, or potentially local or remote code execution in kernel context. The CVSS vector indicates network reachability, low attack complexity, no authentication, and high confidentiality, integrity, and availability impact, but no public exploit maturity is currently reported and EPSS is low at 0.00514.

Why it matters to the business

Systems using affected Linux kernels with VXLAN networking enabled may be exposed to crashes or compromise through crafted network traffic. VXLAN is common in container platforms, virtualization, software-defined networking, cloud overlays, and data center fabrics, so operational impact can include node outages, degraded tenant or workload connectivity, service disruption, and emergency kernel maintenance windows. Although it is not currently listed in CISA KEV and ransomware use is not reported, the high severity and unauthenticated network attack surface make this important to prioritize for internet- or overlay-network-exposed Linux infrastructure.

How an attack unfolds

An attacker able to send traffic that reaches a vulnerable Linux VXLAN processing path crafts packets that cause the VXLAN code to evaluate path MTU handling through skb_tunnel_check_pmtu(). That routine can modify the skb head, invalidating a previously cached ip_hdr() pointer. The vulnerable code then continues using the stale header pointer after the backing memory may have been freed or moved. A simple exploit may trigger an invalid memory access and kernel crash, causing denial of service. A more advanced exploit would attempt to shape heap allocation and packet timing so the freed memory is reclaimed with attacker-influenced data, turning the stale pointer access into controlled memory corruption and possible kernel-level execution. There are no named threat actors or public exploit maturity reported in the supplied data, but the bug class and network-facing kernel path warrant rapid remediation where VXLAN is deployed.

How to fix it

Upgrade to a Linux kernel version that includes the VXLAN fix changing the code to refresh the IP header with ip_hdr(skb) after skb_tunnel_check_pmtu(), rather than reusing a cached pointer. Because no exact fixed package versions were supplied, use the security advisories from the relevant Linux distribution, kernel vendor, appliance vendor, cloud image provider, or embedded platform maintainer to identify the corrected kernel build. Prioritize systems with VXLAN enabled or exposed, including container worker nodes, virtualization hosts, SDN gateways, network appliances, and cloud overlay endpoints. If immediate patching is not possible, reduce exposure by disabling unused VXLAN interfaces, restricting VXLAN UDP ports to trusted peers only, filtering unexpected encapsulated traffic at network boundaries, and isolating overlay network control and data planes. Reboot into the patched kernel after installation and verify the running kernel, not just the installed package, has been updated.

How to confirm the fix worked

Confirm exposure by inventorying Linux systems for VXLAN use and checking the running kernel version against the vendor-fixed version. Look for VXLAN interfaces with commands such as `ip -d link show type vxlan`, `bridge fdb show`, `ss -lunp`, and configuration-management inventories for overlay networking components. Validate remediation by confirming the active kernel after reboot with `uname -a` or distribution package tooling, and by checking that the installed kernel changelog or vendor advisory includes the VXLAN skb_tunnel_check_pmtu()/ip_hdr(skb) fix for this issue. Where feasible, test representative systems in staging with normal VXLAN traffic and MTU/PMTU scenarios to ensure no regressions in overlay connectivity. Exposure is reduced if VXLAN is not loaded, no VXLAN interfaces exist, and UDP VXLAN ports are blocked from untrusted sources, but the durable fix is a patched kernel.

Typical attack path

1. Identify Linux hosts or network appliances that process VXLAN traffic, including hypervisors, Kubernetes nodes, SDN gateways, and overlay-network endpoints.
2. Confirm that VXLAN UDP traffic can reach the target, commonly on UDP/4789 or an environment-specific VXLAN port.
3. Send crafted VXLAN or encapsulated packets that exercise path MTU checking in the vulnerable transmit or forwarding path.
4. Trigger skb_tunnel_check_pmtu() in a way that changes the skb head after the IP header pointer was cached.
5. Cause the kernel to reuse the stale IP header pointer, producing a use-after-free condition.
6. Leverage the condition to crash the kernel or, with advanced heap grooming, attempt kernel memory corruption and privilege escalation or code execution.

How to detect it

To determine whether exploitation may already have occurred, review kernel logs, crash dumps, EDR telemetry, and network records from systems that process VXLAN traffic. Key sources include `dmesg`, journald, `/var/log/kern.log`, `/var/log/messages`, `/var/crash/`, kdump/vmcore artifacts, hypervisor or container-node logs, network IDS/flow logs, and firewall records for VXLAN UDP traffic. Look for sudden kernel panics, general protection faults, page faults, KASAN use-after-free reports, or stack traces involving VXLAN, skb_tunnel_check_pmtu(), ip_hdr(), or tunnel PMTU processing. Network-side, investigate unusual or high-rate VXLAN traffic, unexpected VXLAN peers, malformed encapsulated packets, and bursts of ICMP fragmentation-needed or PMTU-related behavior near crash times. Absence of logs does not rule out exploitation because kernel memory corruption may crash the host before detailed telemetry is written. If a crash occurred, preserve vmcore/kdump data before reboot cleanup and compare packet captures or flow logs immediately preceding the event.

• BUG: KASAN: use-after-free
• use-after-free in vxlan
• vxlan: do not reuse cached ip_hdr
• skb_tunnel_check_pmtu
• ip_hdr(skb)
• general protection fault
• kernel BUG at drivers/net/vxlan
• RIP: vxlan
• Call Trace: vxlan
• Call Trace: skb_tunnel_check_pmtu
• Call Trace: ip_hdr
• UDP/4789
• dst port 4789
• VXLAN
• /var/crash/vmcore
• /var/log/kern.log
• /var/log/messages

What your security team should do

• Prioritize patching Linux systems that terminate or forward VXLAN traffic, especially virtualization hosts, Kubernetes or container nodes, SDN gateways, cloud overlay endpoints, and network appliances.
• Treat this as high operational risk despite low current EPSS because the affected code is in the kernel networking path and the CVSS vector indicates unauthenticated network reachability.
• Inventory VXLAN usage across the fleet by querying kernel modules, VXLAN interfaces, overlay-network components, and listening UDP encapsulation ports.
• Restrict VXLAN traffic to known trusted peers and block unexpected UDP/4789 or environment-specific VXLAN ports at firewalls, security groups, ACLs, and network segmentation controls.
• Monitor for kernel crashes, KASAN use-after-free reports, VXLAN-related stack traces, and unusual bursts of VXLAN/PMTU traffic until patching is complete.
• Ensure patched kernels are actually booted after update; flag systems with updated packages but stale running kernels.
• Track vendor advisories for exact fixed kernel package versions because none were provided in the input data.