CVE-2026-23276: Linux Kernel Tunnel DOS Vulnerability

CVE-2026-23276 Overview

A stack overflow vulnerability exists in the Linux kernel's network tunnel transmit functions (iptunnel_xmit, ip6tunnel_xmit) due to missing recursion limits. When a bond device configured in broadcast mode uses GRE tap interfaces as slaves, and those GRE tunnels route back through the bond, multicast or broadcast traffic can trigger infinite recursion between bond_xmit_broadcast() and ip_tunnel_xmit()/ip6_tnl_xmit(), leading to kernel stack overflow and system crash.

Critical Impact

This vulnerability can cause kernel stack overflow leading to system crashes and potential denial of service conditions on Linux systems with specific network tunnel configurations.

Affected Products

• Linux Kernel (multiple versions with tunnel networking support)
• Systems using bond devices in broadcast mode with GRE tap interfaces
• Systems utilizing UDP encapsulated tunnels (VXLAN, Geneve, etc.)

Discovery Timeline

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

Technical Details for CVE-2026-23276

Vulnerability Analysis

The vulnerability stems from the absence of dedicated recursion limits in Linux kernel tunnel transmit functions. The existing XMIT_RECURSION_LIMIT of 8 in the no-qdisc path proves insufficient because tunnel recursion involves route lookups and full IP output operations, which consume significantly more stack space per recursion level compared to standard packet transmission paths.

The kernel stack trace reveals the recursive call pattern originating from MLD (Multicast Listener Discovery) work processing through the bond device's broadcast transmission path. Each iteration cycles through bond_xmit_broadcast() → ip_tunnel_xmit() → iptunnel_xmit() → ip_output() → ip_finish_output2() → __dev_queue_xmit() and back to bond_xmit_broadcast(), rapidly exhausting available stack space.

KASAN (Kernel Address Sanitizer) detected a stack-out-of-bounds write in blake2s.constprop.0, indicating memory corruption due to the stack overflow condition.

Root Cause

The root cause is the lack of recursion detection and limiting in the iptunnel_xmit() and ip6tunnel_xmit() functions. While the kernel has general transmit recursion protection, the tunnel-specific code paths bypass this protection. The problem is exacerbated when:

1. A bond device operates in broadcast mode with GRE tap interfaces as slaves
2. The GRE tunnel routes are configured to pass traffic back through the bond device
3. Multicast or broadcast traffic enters this circular path

The dev_xmit_recursion helpers were located in net/core/dev.h (a private header), making them inaccessible to the tunnel code in net/ipv4/ip_tunnel_core.c.

Attack Vector

The vulnerability can be triggered through network traffic that causes recursive tunnel transmission. An attacker with the ability to send multicast or broadcast packets to a vulnerable system could potentially cause a denial of service by triggering the infinite recursion. The attack requires the target system to have a specific network configuration involving bond devices with GRE tunnel slaves that create a routing loop.

The recursive transmission pattern visible in the kernel trace demonstrates the vulnerability mechanism:

bond_xmit_broadcast → ip_tunnel_xmit → iptunnel_xmit → ip_output →
ip_finish_output2 → __dev_queue_xmit → bond_xmit_broadcast (repeats)

This cycle continues until the kernel stack is exhausted, triggering the KASAN stack-out-of-bounds detection and subsequent system instability.

Detection Methods for CVE-2026-23276

Indicators of Compromise

• Kernel panic or crash logs indicating stack overflow conditions
• KASAN alerts showing stack-out-of-bounds writes in network-related kernel functions
• System instability when processing multicast/broadcast traffic on bond interfaces with GRE tunnel slaves
• Repeated kernel traces showing recursive calls between bond_xmit_broadcast() and tunnel transmit functions

Detection Strategies

• Monitor for kernel panic events with stack traces containing bond_xmit_broadcast, ip_tunnel_xmit, or iptunnel_xmit functions
• Enable KASAN (Kernel Address Sanitizer) on test systems to detect stack overflow conditions
• Review network configurations for bond devices in broadcast mode using GRE tap interfaces that may create routing loops
• Implement system monitoring for unexpected kernel crashes or reboots

Monitoring Recommendations

• Configure centralized logging to capture kernel panic messages and stack traces
• Deploy monitoring for system availability and unexpected reboots on systems with complex tunnel configurations
• Use kernel tracing tools to monitor recursion depth in network transmit paths during testing
• Establish baseline network behavior metrics to detect anomalous multicast/broadcast traffic patterns

How to Mitigate CVE-2026-23276

Immediate Actions Required

• Apply the latest kernel security patches that implement IP_TUNNEL_RECURSION_LIMIT (value of 4) for tunnel transmit functions
• Review and audit network configurations for bond devices with GRE tunnel slaves to identify potential routing loops
• Temporarily disable broadcast mode on bond devices with tunnel interfaces if patching is not immediately possible
• Monitor affected systems for signs of exploitation or instability

Patch Information

The Linux kernel developers have addressed this vulnerability through multiple commits that add recursion detection using dev_xmit_recursion helpers directly in iptunnel_xmit() and ip6tunnel_xmit() functions. The fix moves the dev_xmit_recursion helpers from net/core/dev.h to the public header include/linux/netdevice.h to enable their use by tunnel code. A new lower recursion limit of 4 (IP_TUNNEL_RECURSION_LIMIT) is implemented to account for the higher stack consumption in tunnel paths.

Patches are available through the following kernel Git commits:

• Kernel Git Commit 6f1a914
• Kernel Git Commit 834c4f6
• Kernel Git Commit 8a57dee
• Kernel Git Commit b56b8d1

Workarounds

• Avoid configuring bond devices in broadcast mode with GRE tap interfaces that route through the same bond
• Reconfigure tunnel routing to prevent circular paths through bond devices
• Consider using alternative bonding modes (e.g., active-backup) that do not broadcast to all slaves
• Implement network segmentation to isolate systems with complex tunnel configurations

# Configuration example - Check for problematic bond configurations
# List bond interfaces and their mode
cat /proc/net/bonding/bond*

# Verify GRE tunnel endpoints don't route through the parent bond
ip route get <tunnel_endpoint_ip>

# Temporarily change bond mode from broadcast (3) to active-backup (1)
# WARNING: This will affect network connectivity - test thoroughly
echo "balance-rr" > /sys/class/net/bond0/bonding/mode