CVE-2026-23276 is a reminder that some of the most dangerous kernel bugs are not glamorous buffer overflows or obvious use-after-free defects, but control-flow problems that only emerge under very specific network topologies. In this case, the Linux kernel fix closes an infinite recursion path between bond-device broadcast handling and tunnel transmit functions, where GRE tap slaves can route traffic back into the same bond and drive the stack into overflow. The patch introduces a dedicated recursion cap for tunnel transmission, lowers the threshold below the generic transmit limit, and broadens recursion detection so all IPv4 and IPv6 tunnel paths are covered. ulnerable code sits at the intersection of Linux bonding, tunnel transmit helpers, multicast delivery, and the IP output path. That matters because each of those subsystems is already stateful on its own, and when they form a loop, the kernel can end up repeatedly re-entering the same logic with little margin for error. The CVE description says the problem was first observed when a bond in broadcast mode had GRE tap interfaces as slaves, and the tunnels sent multicast or broadcast traffic back through the bond.
The kernel’s ordinarrotection was not enough. The existing no-qdisc path uses
XMIT_RECURSION_LIMIT of 8, but that limit was designed for a different class of transmit nesting, not for repeated tunnel resolution and full IP output traversal. The CVE note explicitly says tunnel recursion consumes much more stack per level because it involves route lookups and the full output path, so the generic limit could still allow stack exhaustion before the guard tripped.
That distinction is important for readers protection as a single global safety net. In reality,
what recurses matters as much as
how often it recurses. A loop that only shuttles between lightweight device layers may survive deeper nesting, while a loop that repeatedly enters routing and encapsulation code can burn through stack far faster. The fix for CVE-2026-23276 reflects that difference with a lower tunnel-specific cap of 4, identified in the record as
IP_TUNNEL_RECURSION_LIMIT.
The bug also illustrates how multicast can turn into a reliabilid with device topologies that feed traffic back into themselves. Broadcast mode is legitimate in bonding configurations, and tunnels such as GRE, VXLAN, and Geneve are legitimate deployment tools, but the combination can create a path where the kernel repeatedly hands a packet back to the same transmit chain. That is
exactly the sort of edge case that tends to stay hidden until a real-world deployment triggers it.
At a practical level, this is a denial-of-service class issue first and a memory-safetrnel stack overflow reported in the CVE details is the symptom, while the uncontrolled recursion between
bond_xmit_broadcast() and tunnel transmit functions is the root cause. The CVE text also ties the crash to KASAN evidence, which is a strong sign that maintainers were dealing with an actual memory corruption path rather than a merely theoretical loop.
What Went Wrong
The most direct version of the bug is easy to state: tunnel transmit helpers did nosion limit. Instead, they relied on broader transmit-path protections that were not tailored to the heavier stack usage of tunnel routing and encapsulation. When the recursion involved GRE tap slaves on a bond that also accepted the traffic back in broadcast mode, the result was a transmit loop that could keep climbing until the stack ran out.
Why the generic limit was not enough
The kernel already had a recursion guard in the no-qdisc path, and 8 might sound conserv But the CVE description makes clear that tunnel recursion is not equivalent to simple device recursion. Each level can pull in route lookup, encapsulation handling, IP output, and additional bookkeeping, so the stack footprint per iteration is much larger than the transmit recursion model assumed.
That is why the fix does not merely “raise a limit” or “tweak a counter.” It changes the design by giving tunnel xmit functions a separate recursion cheld. In other words, the kernel now distinguishes between ordinary transmit nesting and tunnel-specific nesting, which is a more accurate model of the risk.
That is the right architectural move, because a single universal cap can be too blunt for modern network stacks.
The stack trace in the CVE text reinforces that assessment. It shows repeated transitions through
ip_output(),
ip_finish_output2(),
__dev_queue_xmit(),
bond_xmit_broadl_xmit(), then back again, which is precisely the sort of repeated cross-subsystem flow that can silently evade a generic recursion guard until it is too late. The trace also shows the crash landing in
blake2s.constprop.0, a reminder that a stack overflow need not fail at the recursion point itself; it can damage later code that merely inherits the corrupted stack state.
The role of bond broadcast mode
Bonding in broadcast mode is legitimate but unusual enough that many operators do not test it against tunnel-heavy topologies. Broadcast mode sends traffic outuseful in certain redundancy or mirroring scenarios. But if one of those slaves is a tunnel endpoint whose route resolves back through the same bond, the kernel can wind up rediscovering its own transmit path with each packet.
This is where the issue becomes more than a simple implementation bug. The behavior is topology-dependent, meaning it may only appear in environments that combine bonding, tunneling, and multicast or broadcast traffic. to detect in ordinary lab setups* and easier to underestimate during review, even though the impact can be severe once the topology exists in production.
The Patch Strategy
The fix for CVE-2026-23276 is notable because it addresses the recursion at the transmit helper boundary, not just somewhere later in the call chain. The record says maintainers added recursion detection using
dpers directly iniptunnel_xmit()
andip6tunnel_xmit()`, ensuring that all IPv4 and IPv6 tunnel paths are protected, including UDP-encapsulated tunnels such as VXLAN and Geneve.
Moving the helpers to a public header
One of the subtler parts of the fix is that
dev_xmit_recursion helpers were moved from
net/core/dev.h into the public header
include/linux/netdevice.h. That sounds like a build-system detail, but it matters becaus access the same recursion machinery that the networking core already uses. Without that move, the tunnel transmit functions would not have had a clean, supported way to perform the check themselves.
This is a small example of a larger kernel-security pattern. Sometimes the most important vulnerability fix is not the limit value itself but the API change that lets the right layer enforce the limit. When the protection lives too deep in one subsystem, sibling subsystems can remainard. The header move signals that the fix was meant to be reusable and maintainable, not just a one-off workaround.
Why the lower limit matters
The CVE description says the new tunnel recursion cap is 4, not 8. That choice suggests maintainers intentionally erred on the side of caution because the per-level stack cost in tunnel recursion is high enough that even moderate nesting is dangerous.
This is a classic def: accepting a lower ceiling on a rare path to prevent catastrophic failure on an even rarer but plausible path.
The change also reflects an important kernel principle: not all recursion is equal, and not all recursion guards should be inherited from generic code. By setting a tunnel-specific limit, the kernel recognizes that the tunnel path is expensive and should be constrained more tightly than routine device transmission. That is espthe recursion includes routing decisions, because route resolution can itself fan out into additional logic before the packet ever leaves the machine.
Broadening protection across tunnel families
A narrow fix would have helped only one tunnel implementation. Instead, the CVE entry says the new recursion detection covers all IPv4 and IPv6 tunnel paths, including UDP-encapsulated overlays like VXLAN and Geneve. That breadth matters because modern networks use multiple overlay technologies intech that only protects GRE would leave plenty of attack surface exposed.
That breadth also signals a defensive mindset: the kernel team is treating tunnel transmit recursion as a
class of problem, not a one-driver bug. In practice, that reduces the chance that a neighboring tunnel implementation will later rediscover the same flaw under a different name. It is the sort of change operators want, because it lowers the odds of patch whack-a-ms Is Security-Relevant
At first glance, this might look like an availability issue only, but kernel stack overflow is never something to treat casually. A repeated recursion path can crash the system outright, and depending on surrounding conditions, a stack overflow may also corrupt memory in a way that becomes security-significant. The CVE text labels the bug with a KASAN sort, which strongly supports the view that this was not just a harmless logic loop.
From crash to control-flow hazard
The direct consequence of this bug is a kernel crash or a forced failure in the networking path. In environments where the networking stack is critical, that alone can be a serious denial-of-service event. But the existence of a stack overflow also means there is an attack surface for memory corruption, which is why issues like this get tracked as CVEs instead of being dismigs.
It is worth emphasizing that exploitability is not the same as impact. The CVE does not claim a public exploit chain, and the record does not provide a CVSS score yet. Still, the fact that the stack overflow was observed under KASAN and involved repeated deep recursion is enough to justify prompt remediation.
Kernel stack exhaustion is one of those problems that can be deceptively simple to trigger and difficult to reason about safelt and broadcast make the issue easier to trigger
Multicast and broadcast traffic are especially relevant because they can traverse devices in ways unicast packets may not. The CVE description specifically says multicast/broadcast traffic triggers the recursion loop in the bond-and-tunnel setup. That means routine discovery traffic, membership traffic, or other group-oriented packets may be sufficient to push the kernel into the dangerous pis present.
This is one reason the issue matters to enterprise network teams. Broadcast-mode bonding is not a default consumer setup, but it is plausible in clustered, mirrored, or laboratory environments where tunnel overlays and redundant links coexist. The vulnerable condition is therefore niche, but not exotic. In kernel security, niche is often enough* if the topology is common in infrastructure deployments.
Enterprise and Infrastructure Impact
The enterprise impact depend more on virtualized, clustered, or appliance-like Linux deployments that use network bonding and overlays. That includes environments where GRE, VXLAN, or Geneve are used for segmentation, migration, or tenant isolation, especially if broadcast or multicast traffic is allowed into a bonding configuration. The CVE’s callout to all IPv4 and IPv6 tunnel paths means operators should think broadly, not only aere this is most likely to matter
Operators should pay attention to systems that combine multiple network abstractions in the same host. That includes hypervisors, container hosts with overlay networking, lab routers, and appliances that aggregate interfaces for resilience. The risk is higher when packet paths are complex enough that traffic can be reintroduced into the same bond device after encapsulation.
For consumer systems, the practical exposure is probably lower. Most desktops and laptops do not run bondeast mode, nor do they typically participate in GRE or VXLAN topologies. Even so,
low consumer exposure does not mean low importance; it simply means the patch priority is dominated by infrastructure operators rather than endpoint users.
Why cloud and virtualization teams should care
Cloud and virtualization teams often rely on overlay networks precisely because they simplify tenant separation and routing fleayers can make it easier to accidentally create recursive transmit paths if virtual NICs, bonds, and tunnels are composed in unusual ways. A bug like this is especially relevant in test, staging, and edge environments where topologies are repeatedly reconfigured.
A useful way to think about the risk is to imagine the packet path as a loop rather than a line. The keansmit once, encapsulate once, and exit. When the topology causes the output path to rediscover itself, the packet becomes a recursive input to the same machinery that is trying to send it out. That is where stack consumption explodes.
Technical Anatomy of the Call Chain
The provided stack trace is valuable because it shows the bug’s shape in real code rather than in abstract terms. It starts in multicast group work, travels through bonding broadcast lansmit code, and then re-enters the general output path repeatedly. The cycle between
bond_xmit_broadcast() and
ip_tunnel_xmit() /
ip6_tnl_xmit() is the heart of the defect.
Reading the loop
The trace shows a repeating sequence:
bond_start_xmit(),
bond_xmit_broadcast(),
__dev_queue_xmit(),
ip_finish_output2(),
ip_output(), and then back i/
ip_tunnel_xmit() and
gre_tap_xmit(). That repeated choreography is a good illustration of how a network packet can be legitimate at every individual step while still becoming dangerous as a whole. Each component does the expected thing, but the composition creates a recursion trap.
The trace also indicates the work item involved was
mld_ifc_work, which means multicast listener discovery traffic is part of the triggeringimportant because it tells defenders the trigger is not necessarily user-initiated application traffic; protocol maintenance traffic can be enough. The result is a risk surface that may appear idle until network housekeeping activity exposes it.
Why stack depth matters more than call count
The kernel often has recursion protections because repeated transmit loops are not rare in networking code. But the CVE description explicitly says the ordinary 8-level limit is not enough here. Ty tunnel recursion level includes more stack-heavy work than a normal xmit recursion path, so the same count translates into much larger memory pressure.
That detail should matter to defenders and developers alike. It is easy to reason about recursion as a simple integer, but
the cost per recursion frame is the real issue. If one frame is light and another frame is heavy, the same threshold can be safe introphic in another. CVE-2026-23276 is a textbook example of that asymmetry.
Why the Public Header Move Matters
Kernel header placement is often treated as an implementation footnote, but this patch uses that mechanism to make the recursion helpers available where they were previously hidden. Moving
dev_xmit_recursion helpers from
net/core/dev.h to
include/linux/netdevice.h makes them visible to tunnel co if tunnel transmit functions are expected to enforce their own recursion guard.
API visibility as a security control
This is a good example of how kernel security often depends on API boundaries. If the right helper is not visible to the right layer, the layer cannot perform its own safety check even if it knows it should. By promoting the helperhe fix turns a private core mechanism into a reusable safeguard for tunneling code.
That change is also a maintainability win. Security fixes that depend on hidden internals are harder to backport cleanly, harder to audit later, and easier to accidentally break when nearby code is refactored. Public exposure of the helper makes the new recursion rule easier to preserve across kernel versions.
In security engineering terms, this is a durability rrectness tweak.
A lesson for future kernel hardening
The broader lesson is that defenses need to live close to the risky behavior they are meant to constrain. Tunnel xmit functions are the right place to detect tunnel recursion because that is where the recursion semantics are clearest. Placing the guard there reduces reliance on indirect side effects in generic transmiderstand encapsulation-specific stack cost.
That approach is likely to scale better as the network stack evolves. Modern Linux networking is not a single path but a mesh of overlays, offloads, bridges, bonds, and queue disciplines. If recursion checks live only in one place, the next new transport abstraction may bypass them inadvertently. This patch shows the maintainers are thinking about that class .
Strengths and Opportunities
The fix has several strengths that make it a well-targeted and relatively low-risk hardening change. It is narrowly focused on the actual recursion loop, but it also improves the kernel’s resilience to similar tunnel-topology mistakes in the future. That combination is exactly what operators want from a networking security patch.
- The patch addresses the real failure mode: infinite broadcast handling and tunnel xmit paths.
- The new tunnel-specific limit is lower and better aligned with stack usage than the generic transmit limit.
- Recursion detection is added at the tunnel helper boundary, where the risk is easiest to identify.
- Coverage extends beyond GRE to IPv4, IPv6, and UDP-encapsulated tunnels such as VXLAN and Geneve.
- The public-header move makeand easier to maintain across future changes.
- The fix should reduce the odds of similar recursion bugs being reintroduced in adjacent code.
- Because the change is conceptual rather than architectural, it should be easier to backport into stable kernels.
Risks and Concerns
Even a good patch leaves operational questions behind, and this one is no exception. Thhat unusual network topologies may continue to lurk in production environments where the exact loop was never tested, meay not realize they were exposed until they review the topology carefully. The patch reduces risk, but it also eto build self-referential network paths accidentally.
- Systems using bond broadcast mode with tunnediate review, especially in mixed overlay environments.
- Multicast and broadcast traffic can trigget an obvious malicious payload.
- The vulnerability is topology-dependent, so standard lab testinators might underestimate the issue if they focus only on GRE and ignore VXLAN or Geneve.
- A stntly risky because it can manifest as both denial of service and memory corruption.
- If downstream vendors lag on -lived enterprise kernels could remain exposed for longer than expected.
- The public-header change is useful, but it also means future networking patches must respect the new API surface carefully.
Looking Ahead
The most important near-term question is how quickly downstream kernel maintainers absorb the fix into supported stable lines. The CVE entry already points to stable references, which is a good sign, but the real-world security posture wily enterprise distributions and appliance vendors integrate the patch. As with many kernel issues, the upstream fix is only theion.
It is also worth watching whether related tunnel or bonding code receives additional hardeniis surfaces, maintainers often review adjacent transmit paths for similar recursially where offloads, encapsulation, or multicast fan-out are involved.
That kind of follow-up ree next bug is prevented before it gets a CVE number.
- Watch for stable backports in major distribution kernelre streams.
- Check whether your environment uses bond broadcast mode with GRE, VXLAN, or Geneve tunnels.
- Review multicast paths that could loop back into the same bond.
- Verify whether your kernel build includes the new tunnel recursion limit and hanges.
- Reassess lab and staging topologies, not just production, because recursion bugs often surface there first.
For Linux administrators, the lesson is straightforward: network recursion guards are not one-size-fits-all, and overlay-heavy infrastructures can create stack pressure that generic transmit limits do not safely contain. For everyone else, CVE-2026-23276 is a useful example of why kernel security keeps turning up in pure networking plumbing. A small change to a transmit helper can mean the difference between a stable network path and a kernel that can be driven into self-referential collapse.
Source: NVD / Linux Kernel
Security Update Guide - Microsoft Security Response Center