CVE-2026-23293: Linux Kernel Buffer Overflow Vulnerability

CVE-2026-23293 Overview

CVE-2026-23293 is a NULL pointer dereference vulnerability in the Linux kernel's VXLAN (Virtual Extensible LAN) network driver. The vulnerability occurs when the system is booted with IPv6 disabled via the ipv6.disable=1 kernel parameter. Under this configuration, the neighbor discovery table (nd_tbl) is never initialized because inet6_init() exits before ndisc_init() is called. When an IPv6 packet is subsequently injected into a VXLAN interface, the route_shortcircuit() function is invoked, leading to a NULL pointer dereference in neigh_lookup().

Critical Impact

This vulnerability can cause a kernel panic and system crash when IPv6 packets are processed on VXLAN interfaces while IPv6 is disabled at the kernel level, potentially leading to denial of service conditions.

Affected Products

• Linux kernel with VXLAN module
• Systems configured with ipv6.disable=1 boot parameter
• Linux kernel versions prior to the security patches

Discovery Timeline

• 2026-03-25 - CVE CVE-2026-23293 published to NVD
• 2026-03-25 - Last updated in NVD database

Technical Details for CVE-2026-23293

Vulnerability Analysis

The vulnerability stems from an uninitialized data structure in the Linux kernel's IPv6 neighbor discovery subsystem. When the kernel boots with IPv6 disabled (ipv6.disable=1), the initialization sequence in inet6_init() terminates early, preventing ndisc_init() from being called. This function is responsible for initializing the nd_tbl structure, which is the neighbor discovery table used for IPv6 address resolution.

The VXLAN driver's route_shortcircuit() function does not validate whether IPv6 is properly initialized before attempting to perform neighbor lookups. When an IPv6 packet (identified by ETH_P_IPV6 protocol) reaches this code path, the driver calls neigh_lookup() with the uninitialized nd_tbl, resulting in a NULL pointer dereference at address 0x0000000000000380.

The crash occurs in the following call chain:

1. packet_sendmsg() - User-space packet injection
2. __dev_queue_xmit() - Device queue transmission
3. dev_hard_start_xmit() - Hardware transmission initiation
4. vxlan_xmit() - VXLAN transmit handler
5. neigh_lookup() - NULL dereference occurs here

Root Cause

The root cause is a missing safety check in the VXLAN driver's route_shortcircuit() function. The driver assumes that if it receives an IPv6 packet, the IPv6 subsystem must be properly initialized. However, this assumption is invalid when IPv6 is explicitly disabled at boot time via kernel parameters. The fix adds an early return check in route_shortcircuit() when the protocol is ETH_P_IPV6 and IPv6 is disabled.

Notably, the commonly used ipv6_mod_enabled() helper function cannot be used in this context because VXLAN can be built as a built-in kernel component even when IPv6 is configured as a loadable module.

Attack Vector

An attacker with the ability to inject network packets into a VXLAN interface can trigger this vulnerability. The attack scenario involves:

1. Target system must be configured with ipv6.disable=1 boot parameter
2. VXLAN interfaces must be configured and active
3. Attacker injects an IPv6 packet (raw socket, packet injection, or network-based)
4. The kernel processes the packet through the VXLAN transmit path
5. NULL pointer dereference causes kernel panic and system crash

This vulnerability can be exploited locally through raw sockets or potentially remotely if the attacker can deliver IPv6 packets to the VXLAN interface from the network underlay.

Detection Methods for CVE-2026-23293

Indicators of Compromise

• Kernel panic messages containing BUG: kernel NULL pointer dereference, address: 0000000000000380
• Stack traces showing neigh_lookup+0x20/0x270 in the RIP register
• Call traces including vxlan_xmit, dev_hard_start_xmit, and packet_sendmsg
• System crashes occurring on hosts with VXLAN interfaces and ipv6.disable=1 configuration

Detection Strategies

• Monitor kernel logs (dmesg, /var/log/kern.log) for NULL pointer dereference events in the vxlan module
• Implement automated crash dump analysis to identify the specific crash signature
• Deploy kernel tracing (ftrace/eBPF) to monitor neigh_lookup() calls with NULL table parameters
• Configure crash collection services to capture and analyze kernel panics matching this pattern

Monitoring Recommendations

• Enable kernel crash dump collection (kdump) to preserve evidence of exploitation attempts
• Set up alerts for system reboots following kernel panics on VXLAN-enabled hosts
• Monitor for unusual IPv6 packet activity on systems configured with IPv6 disabled
• Implement network monitoring to detect packet injection attempts targeting VXLAN interfaces

How to Mitigate CVE-2026-23293

Immediate Actions Required

• Apply the kernel security patches from the stable kernel tree immediately
• If patching is not immediately possible, consider disabling VXLAN interfaces on systems with ipv6.disable=1
• Review and audit systems that use both VXLAN networking and have IPv6 disabled
• Restrict access to raw socket capabilities to limit local exploitation potential

Patch Information

Security patches have been released to the Linux kernel stable tree. The fix adds an early check in route_shortcircuit() to safely handle IPv6 packets when IPv6 is disabled at the kernel level.

Available patches:

• Kernel Patch Commit 168ff39
• Kernel Patch Commit 5f93e6b
• Kernel Patch Commit abcd48e
• Kernel Patch Commit b5190fc
• Kernel Patch Commit f0373e9
• Kernel Patch Commit fbbd211

Workarounds

• Remove the ipv6.disable=1 boot parameter if IPv6 functionality is acceptable in your environment
• Disable or unload the VXLAN kernel module (rmmod vxlan) on affected systems until patching is complete
• Implement network-level filtering to drop IPv6 packets before they reach VXLAN interfaces
• Use network namespaces or container isolation to limit exposure of vulnerable VXLAN configurations

# Check if system is vulnerable (IPv6 disabled with VXLAN loaded)
cat /proc/cmdline | grep -q "ipv6.disable=1" && lsmod | grep -q vxlan && echo "VULNERABLE"

# Temporary workaround: unload VXLAN module if not in use
sudo rmmod vxlan

# Verify kernel version after patching
uname -r