From: Tristan Madani <tristan@talencesecurity.com>

Virtual network devices (ipvlan, macvlan, bonding) can enter legitimate
transmit recursion when combined with packet forwarding configurations
such as IPVS NAT.  The existing XMIT_RECURSION_LIMIT (8) in
__dev_queue_xmit() detects and breaks these loops, but the allowed
depth is too high for KASAN-instrumented kernels: each recursion level
consumes significantly more stack due to KASAN inline instrumentation,
and the cumulative usage overflows the kernel stack before the limit
fires.

On x86_64, CONFIG_KASAN_GENERIC doubles THREAD_SIZE from 16KB to 32KB
(KASAN_STACK_ORDER=1), but KASAN per-access checks inflate individual
function frames by roughly 2-3x.  For an ipvlan L3 + IPVS NAT routing
loop, objdump measurements on a non-KASAN kernel show ~1.4KB of stack
consumed per recursion level (across 17 functions from __dev_queue_xmit
through the full IP output path and back).  At KASAN ~2.3x inflation
factor that becomes ~3.3KB per level.  Eight levels -- the current
limit -- consume ~26KB plus the initial call chain (~8KB), which
exceeds the 32KB KASAN stack.  The overflow hits the VMAP_STACK guard
page and causes a non-recoverable kernel panic (BUG: stack guard page
was hit).

On non-KASAN kernels the same loop is safely caught by the existing
limit: the "Dead loop on virtual device" message fires and the packet
is dropped without any stack overflow.

Reduce XMIT_RECURSION_LIMIT to 4 when CONFIG_KASAN is enabled.

The deepest legitimate transmit recursion observed in the kernel
selftests is 5 levels of __dev_queue_xmit nesting, in VXLAN symmetric
routing topologies with VRF (vxlan_symmetric, vxlan_asymmetric):

  __dev_queue_xmit(vrf)             depth 1
    __dev_queue_xmit(vlan-svi)      depth 2
      __dev_queue_xmit(bridge)      depth 3
        __dev_queue_xmit(vxlan)     depth 4
          __dev_queue_xmit(veth)    depth 5

Since the recursion check fires when the counter exceeds the limit
(strictly greater than), a limit of 4 permits 5 levels of nesting
while blocking the 6th.  At ~3.3KB per level, five levels consume
~16.5KB; combined with the ~8KB initial call chain, total usage is
~24.5KB -- well within the 32KB KASAN stack with ~7.5KB of margin.

A limit of 3 (v2/v3 of this patch) allows only 4 levels, which broke
the VXLAN symmetric selftests: the 5th __dev_queue_xmit call was
incorrectly dropped, as reported by Jakub Kicinski and the kernel test
robot.

The recursion path triggering this is:

  __dev_queue_xmit -> dev_hard_start_xmit -> ipvlan_start_xmit
  -> ipvlan_queue_xmit -> ipvlan_process_outbound -> ip_local_out
  -> nf_hook (IPVS) -> ip_vs_in_hook -> ip_vs_nat_xmit -> ip_output
  -> ip_finish_output2 -> neigh_resolve_output -> __dev_queue_xmit

Tested:
  - KASAN kernel (6.8.12 x86_64): panic before fix, "Dead loop"
    drop after fix (at recursion level 4 instead of 8).
  - Non-KASAN kernel (6.8.12 x86_64): "Dead loop" drop both before
    and after fix (no behavior change for production kernels).
  - Measured max __dev_queue_xmit nesting depth via bpftrace in a
    VXLAN symmetric cross-VLAN topology (VRF + VLAN + bridge + VXLAN +
    veth underlay): 5 levels, confirming limit=4 is sufficient.

Fixes: 2ad7bf363841 ("ipvlan: Initial check-in of the IPVLAN driver.")
Cc: stable@vger.kernel.org
Signed-off-by: Tristan Madani <tristan@talencesecurity.com>
---
v4: Raise the KASAN limit from 3 to 4 after investigating the recursion
    depth of VXLAN symmetric forwarding selftests.  Measured max nesting
    depth of 5 via bpftrace (VRF + VLAN + bridge + VXLAN + underlay),
    which requires limit >= 4.  Limit 3 (v2/v3) incorrectly dropped the
    5th call, breaking cross-VLAN tests, as reported by Jakub Kicinski
    and the kernel test robot.

v3: Resend as new thread per Jakub Kicinski request (no code change
    from v2).

v2: Switch from per-driver recursion guard in ipvlan_core.c to
    reducing the global XMIT_RECURSION_LIMIT under CONFIG_KASAN,
    as suggested by Eric Dumazet.
    https://lore.kernel.org/20260711204700.1760374-1-tristmd@gmail.com

v1: https://lore.kernel.org/20260711134732.1385563-1-tristmd@gmail.com
 include/linux/netdevice.h | 4 ++++
 1 file changed, 4 insertions(+)

diff --git a/include/linux/netdevice.h b/include/linux/netdevice.h
index 87cafc932e9e6..3ccd1e65bcd9e 100644
--- a/include/linux/netdevice.h
+++ b/include/linux/netdevice.h
@@ -3669,7 +3669,11 @@ struct page_pool_bh {
 };
 DECLARE_PER_CPU(struct page_pool_bh, system_page_pool);
 
+#ifdef CONFIG_KASAN
+#define XMIT_RECURSION_LIMIT	4
+#else
 #define XMIT_RECURSION_LIMIT	8
+#endif
 
 #ifndef CONFIG_PREEMPT_RT
 static inline int dev_recursion_level(void)
-- 
2.47.3

Thank you for your contribution! Sashiko AI review found 3 potential
issue(s) to consider:

Critical: 0 · High: 1 · Medium: 2 · Low: 0

- [High] The new KASAN value XMIT_RECURSION_LIMIT=4
  (include/linux/netdevice.h:3673) is sized as if…
- [Medium] The reduction is gated on the umbrella symbol CONFIG_KASAN
  (include/linux/netdevice.h:3672), which is also set for…
- [Medium] The patch lowers only XMIT_RECURSION_LIMIT (to 4 under
  CONFIG_KASAN) and leaves IP_TUNNEL_RECURSION_LIMIT at 5…

--

net: reduce XMIT_RECURSION_LIMIT under KASAN

This halves XMIT_RECURSION_LIMIT from 8 to 4 when CONFIG_KASAN is set, on
the grounds that KASAN-inflated stack frames overflow the 32KB KASAN stack
before the existing limit of 8 fires.  The changelog states that a limit of
4 still permits the 5 levels of __dev_queue_xmit nesting used by the VXLAN
symmetric selftests, while a limit of 3 (v2/v3) broke them.

> diff --git a/include/linux/netdevice.h b/include/linux/netdevice.h
> index 87cafc932e9e6..3ccd1e65bcd9e 100644
> --- a/include/linux/netdevice.h
> +++ b/include/linux/netdevice.h
> @@ -3669,7 +3669,11 @@ struct page_pool_bh {
>  };
>  DECLARE_PER_CPU(struct page_pool_bh, system_page_pool);
>  
> +#ifdef CONFIG_KASAN
> +#define XMIT_RECURSION_LIMIT	4
> +#else
>  #define XMIT_RECURSION_LIMIT	8
> +#endif

[Severity: High]
Is the new value of 4 actually enough for the topology quoted in the
changelog?

The counter compared against XMIT_RECURSION_LIMIT is not a count of
__dev_queue_xmit() nesting only.  dev_xmit_recursion() reads
softnet_data.xmit.recursion, and the tunnel and BPF helpers increment that
same counter:

include/linux/netdevice.h:
	static inline bool dev_xmit_recursion(void)
	{
		return unlikely(__this_cpu_read(softnet_data.xmit.recursion) >
				XMIT_RECURSION_LIMIT);
	}

net/ipv4/ip_tunnel_core.c:iptunnel_xmit() {
	...
	dev_xmit_recursion_inc();
	...
	err = ip_local_out(net, sk, skb);
	...
}

In the vrf -> vlan-svi -> bridge -> vxlan -> veth chain from the changelog,
vxlan_xmit_one() -> udp_tunnel_xmit_skb() -> iptunnel_xmit() adds one
increment between the 4th and the 5th __dev_queue_xmit().  All five devices
are IFF_NO_QUEUE, so each one also takes the check-and-increment branch in
__dev_queue_xmit().  Does the counter therefore reach 5 by the time
__dev_queue_xmit(veth) runs its check, making 5 > 4 true and sending the
packet to recursion_alert:

net/core/dev.c:__dev_queue_xmit() {
	...
recursion_alert:
		net_crit_ratelimited("Dead loop on virtual device %s (net %llu), fix it urgently!\n", ...);
		rc = -ENETDOWN;
	...
}

If so, the 5th level is dropped exactly as with the limit of 3 in v2/v3 that
the changelog says broke vxlan_symmetric/vxlan_asymmetric, and the KASAN
limit would need to be 5 or higher (or a counter dedicated to
__dev_queue_xmit nesting) for the documented worst case to pass.

The same extra unit of the shared budget is consumed by ip6tunnel_xmit() for
IPv6 tunnels, by the lwtunnel output/xmit/input paths, and by
__bpf_tx_skb() -> dev_queue_xmit(), so IPv6 and BPF-redirect variants of
these topologies would lose a level too.

[Severity: Medium]
Should the reduction key on CONFIG_KASAN, or on the KASAN modes that
actually grow stack usage?

CONFIG_KASAN is also set for Hardware Tag-Based KASAN, where neither the
stack size nor the per-frame usage changes:

arch/arm64/include/asm/memory.h:
	#if defined(CONFIG_KASAN_GENERIC) || defined(CONFIG_KASAN_SW_TAGS)
	...
	#define KASAN_THREAD_SHIFT	1
	#else
	#define KASAN_THREAD_SHIFT	0
	#endif
	#define MIN_THREAD_SHIFT	(14 + KASAN_THREAD_SHIFT)

lib/Kconfig.kasan:
	config KASAN_STACK
		bool "Stack instrumentation (unsafe)" if CC_IS_CLANG && !COMPILE_TEST
		depends on KASAN_GENERIC || KASAN_SW_TAGS

So an arm64 CONFIG_KASAN_HW_TAGS=y build keeps MIN_THREAD_SHIFT at 14 (the
same 16KB stack as a non-KASAN kernel) and cannot enable stack
instrumentation, yet the transmit recursion budget drops from 8 to 4.  Does
that make dev_xmit_recursion() reject nesting depths that the
identically-sized non-KASAN kernel forwards, dropping packets with
-ENETDOWN / SKB_DROP_REASON_RECURSION_LIMIT via recursion_alert in
__dev_queue_xmit()?  Would gating on CONFIG_KASAN_GENERIC ||
CONFIG_KASAN_SW_TAGS (or CONFIG_KASAN_STACK) be more accurate?

[Severity: Medium]
This change also leaves the tunnel limit and its comment out of sync.

include/net/ip_tunnels.h still says:

	/* Recursion limit for tunnel xmit to detect routing loops.
	 * Unlike XMIT_RECURSION_LIMIT (8) used in the no-qdisc path, tunnel
	 * recursion involves route lookups and full IP output, consuming much
	 * more stack per level, so a lower limit is needed.
	 */
	#define IP_TUNNEL_RECURSION_LIMIT	5

On CONFIG_KASAN builds the quoted value of 8 is no longer correct, and the
documented ordering is inverted since 5 > 4.  Both limits are compared
against the same counter through dev_recursion_level() /
dev_xmit_recursion().  Should the comment be updated, or should
IP_TUNNEL_RECURSION_LIMIT be made KASAN-aware as well?

Related to that: the generic check is only reached in the noqueue branch of
__dev_queue_xmit():

net/core/dev.c:__dev_queue_xmit() {
	...
	q = rcu_dereference_bh(txq->qdisc);
	trace_net_dev_queue(skb);
	if (q->enqueue) {
		rc = __dev_xmit_skb(skb, q, dev, txq);
		goto out;
	}
	...
}

GRE/ipip/sit devices are not IFF_NO_QUEUE, so a routing loop through them is
bounded only by IP_TUNNEL_RECURSION_LIMIT and still gets 6 nested levels of
the heaviest frames (full route lookup plus IP output) on a KASAN kernel.
Does the new limit have any effect on those loops, given that the changelog
describes stack overflow as the problem being closed?

-- 
Sashiko AI review · https://netdev-ai.bots.linux.dev/sashiko/#/patchset/20260902123040.2172805-1-tristmd%40gmail.com