CVE-2026-63993: Linux Kernel VXLAN Use-After-Free Flaw

CVE-2026-63993 Overview

CVE-2026-63993 is a use-after-free (UAF) vulnerability in the Linux kernel's Virtual Extensible LAN (VXLAN) driver. The flaw occurs in the VXLAN transmit path where the kernel caches an ip_hdr() pointer as old_iph and reuses it after calling skb_tunnel_check_pmtu(). Because skb_tunnel_check_pmtu() can modify skb->head, the cached IP header pointer becomes stale and can reference freed memory. The upstream fix replaces the reuse of old_iph with a fresh ip_hdr(skb) call, mirroring the pattern already used in drivers/net/bareudp.c and drivers/net/geneve.c. The issue was reported by Sashiko and resolved across multiple stable kernel branches.

Critical Impact
A network-reachable attacker can trigger the use-after-free through crafted VXLAN traffic, potentially leading to kernel memory corruption, denial of service, or code execution in kernel context.

Affected Products

Linux kernel VXLAN driver (drivers/net/vxlan/vxlan_core.c)
Systems using VXLAN tunneling for overlay networking
Container and virtualization platforms relying on Linux VXLAN (Kubernetes CNI, OpenStack, Docker overlay networks)

Discovery Timeline

2026-07-19 - CVE-2026-63993 published to NVD
2026-07-20 - Last updated in NVD database

Technical Details for CVE-2026-63993

Vulnerability Analysis

The vulnerability resides in the VXLAN transmit path within the Linux kernel networking stack. The affected code caches the return value of ip_hdr(skb) into a local variable named old_iph before performing path MTU discovery via skb_tunnel_check_pmtu(). The PMTU check can reallocate or modify the socket buffer's linear data area, invalidating any previously obtained pointers into skb->head. Subsequent dereferences of old_iph then operate on freed or reallocated memory, producing a classic use-after-free condition.

Root Cause

The root cause is unsafe pointer caching across a function call that can mutate skb->head. Kernel developers had already addressed the same pattern in the bareudp and geneve tunnel drivers, but the equivalent fix was not applied to VXLAN. The corrected code refetches the IP header by calling ip_hdr(skb) after skb_tunnel_check_pmtu() returns, ensuring the pointer always references valid, current memory.

Attack Vector

Exploitation requires an attacker to trigger the VXLAN transmit path with traffic that forces PMTU handling. Because VXLAN encapsulates traffic over UDP and is commonly exposed on network-facing interfaces of hypervisors, container hosts, and gateways, the attack vector is remote and network-based. Successful triggering can corrupt kernel memory, crash the host, or lead to privilege escalation depending on heap layout and the reallocation state of skb->head.

No public proof-of-concept exploit code is currently available for this issue. Refer to the Linux Kernel Commit 5303925 and companion stable-tree patches for the exact source-level change.

Detection Methods for CVE-2026-63993

Indicators of Compromise

Unexpected kernel oops or panic messages referencing vxlan_xmit, skb_tunnel_check_pmtu, or ip_hdr in dmesg or /var/log/kern.log.
KASAN (Kernel Address Sanitizer) reports indicating use-after-free access within the VXLAN transmit path on instrumented kernels.
Sudden host instability or kernel crashes correlated with VXLAN-encapsulated traffic bursts on tunnel endpoints.

Detection Strategies

Inventory running kernels across hosts and compare against the fixed stable versions listed in the kernel.org stable commits.
Enable KASAN on non-production kernels handling VXLAN traffic to surface memory corruption during fuzzing and load testing.
Monitor host telemetry for abnormal kernel crash rates on nodes that terminate VXLAN tunnels, such as Kubernetes worker nodes using Flannel, Calico VXLAN mode, or Cilium VXLAN.

Monitoring Recommendations

Aggregate kernel.log, journalctl -k, and crash-dump artifacts into a central data lake for correlation across fleet-wide VXLAN endpoints.
Alert on kernel warnings referencing tunnel or PMTU functions, especially on hosts that have not yet been patched.
Track VXLAN traffic anomalies (unusual fragmentation, PMTU black holes, oversized encapsulated packets) that could indicate exploitation attempts.

How to Mitigate CVE-2026-63993

Immediate Actions Required

Apply the upstream Linux kernel patches that replace old_iph reuse with a fresh ip_hdr(skb) call in the VXLAN driver.
Update to a Linux stable release that includes the fix commits referenced in the NVD advisory, then reboot affected hosts.
Prioritize patching on any host that terminates VXLAN tunnels from untrusted networks or multi-tenant workloads.

Patch Information

The fix is distributed across multiple stable kernel branches. Refer to the following commits: 5303925, 609e633, 6b8bfce, 7d9ef0c, 8d435d6, 9257f56, a493efd, and dc3bfa0. Consume distribution-provided kernel updates from Red Hat, SUSE, Ubuntu, or Debian as they become available.

Workarounds

Where VXLAN is not required, unload the vxlan kernel module and blacklist it to eliminate the attack surface entirely.
Restrict UDP traffic on the VXLAN destination port (default 4789) at network boundaries so only trusted endpoints can reach VXLAN sockets.
Isolate multi-tenant workloads on hosts that cannot be patched immediately, reducing the population of untrusted senders able to reach the VXLAN transmit path.

bash

# Verify VXLAN module status and disable if not required
lsmod | grep vxlan
sudo modprobe -r vxlan
echo "blacklist vxlan" | sudo tee /etc/modprobe.d/blacklist-vxlan.conf

# Confirm running kernel version after patching
uname -r