PatchSiren

PatchSiren cyber security CVE debrief

CVE-2026-23276 Linux CVE debrief

CVE-2026-23276 describes a Linux kernel networking flaw where tunnel transmit paths did not enforce an adequate recursion limit of their own. In the affected topology, a bond device in broadcast mode with GRE tap interfaces as slaves can loop multicast or broadcast traffic back through the bond, causing repeated recursion between `bond_xmit_broadcast()` and `ip_tunnel_xmit()`/`ip6_tnl_xmit()` until the kernel stack overflows. The supplied fix raises the defensive bar by adding direct recursion detection in `iptunnel_xmit()` and `ip6tunnel_xmit()` and by using a lower tunnel-specific limit of 4 rather than relying on the existing no-qdisc recursion limit of 8. The patch also applies the helper-based check across IPv4/IPv6 tunnel paths, including UDP-encapsulated tunnels such as VXLAN and Geneve.

Vendor
Linux
Product
Unknown
CVSS
Unknown
CISA KEV
Not listed in stored evidence
Original CVE published
2026-03-20
Original CVE updated
2026-03-25
Advisory published
2026-03-20
Advisory updated
2026-03-25

Who should care

Linux kernel operators and distro/kernel maintainers should care, especially in environments that use bonded interfaces in broadcast mode, GRE tap devices, or other tunnel-based overlay networking. Network teams running multicast or broadcast-heavy workloads should prioritize review if those interfaces can feed traffic back into the same bond.

Technical summary

The issue is a recursion-control gap in tunnel egress handling. According to the supplied CVE description, `iptunnel_xmit()` and `ip6tunnel_xmit()` lacked their own recursion limit, so traffic could recurse through bonding broadcast transmission and tunnel output repeatedly. The fix adds tunnel-specific recursion checks via `dev_xmit_recursion` helpers and uses `IP_TUNNEL_RECURSION_LIMIT` of 4 to reduce stack consumption per level. The remediation is intended to cover the IPv4 and IPv6 tunnel paths broadly, including UDP-encapsulated tunnel devices.

Defensive priority

High for affected deployments. The issue is a kernel stack overflow / denial-of-service risk in a specific but realistic network topology, and it affects core networking paths.

Recommended defensive actions

  • Apply the Linux kernel/stable updates that contain the fix referenced by the supplied kernel.org stable commit links.
  • Review whether any hosts use bond devices in broadcast mode together with GRE tap interfaces or other tunnel devices that can route traffic back through the bond.
  • Temporarily reduce exposure by disabling unnecessary broadcast-mode bonding or tunnel configurations where operationally feasible.
  • Validate post-update behavior in environments that rely on multicast/broadcast traffic, especially where VXLAN, Geneve, GRE, or similar tunnels are used.
  • Monitor affected hosts for kernel stack-overflow symptoms or repeated crashes in networking workqueues during rollout.

Evidence notes

The source description explicitly states that tunnel transmit functions (`iptunnel_xmit`, `ip6tunnel_xmit`) lacked a dedicated recursion limit and that a bond device in broadcast mode with GRE tap slaves could recurse indefinitely, leading to kernel stack overflow. The description also states the remediation: add recursion detection using `dev_xmit_recursion` helpers directly in `iptunnel_xmit()` and `ip6tunnel_xmit()`, lower the limit to 4, and move the helpers into a public header so tunnel code can use them. The supplied timeline shows CVE publication on 2026-03-20 and modification on 2026-03-25, and the NVD metadata marks the item as `Undergoing Analysis`. The four git.kernel.org stable links are the official remediation references supplied in the record.

Official resources

Public CVE publication date in the supplied timeline is 2026-03-20T09:16:13.370Z, with a last modification on 2026-03-25T11:16:21.820Z. NVD currently lists the record as Undergoing Analysis.