[PATCH net v3] net: reduce XMIT_RECURSION_LIMIT under KASAN

[PATCH net v3] net: reduce XMIT_RECURSION_LIMIT under KASAN

[Tristan Madani]

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 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.  Nine levels -- reached before the
current limit fires -- total ~30KB plus the initial call chain, 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 3 when CONFIG_KASAN is enabled.  This
keeps the recursion counter well within the 32KB KASAN stack budget
while preserving the established limit of 8 for production kernels.

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.
  - Non-KASAN kernel (6.8.12 x86_64): "Dead loop" drop both before
    and after fix (no behavior change for production kernels).

Fixes: 2ad7bf363841 ("ipvlan: Initial check-in of the IPVLAN driver.")
Cc: stable@vger.kernel.org
Signed-off-by: Tristan Madani <tristan@talencesecurity.com>
---
v3:
 - no changes, repost per maintainer request
v2: 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 9981d637f8b54..bdcb61d352afb 100644
--- a/include/linux/netdevice.h
+++ b/include/linux/netdevice.h
@@ -3640,7 +3640,11 @@ struct page_pool_bh {
 };
 DECLARE_PER_CPU(struct page_pool_bh, system_page_pool);

+#ifdef CONFIG_KASAN
+#define XMIT_RECURSION_LIMIT	3
+#else
 #define XMIT_RECURSION_LIMIT	8
+#endif

 #ifndef CONFIG_PREEMPT_RT
 static inline int dev_recursion_level(void)
--
2.47.3

Re: [PATCH net v3] net: reduce XMIT_RECURSION_LIMIT under KASAN

[Jakub Kicinski]

On Mon, 27 Jul 2026 20:04:54 +0000 Tristan Madani wrote:
> +#ifdef CONFIG_KASAN
> +#define XMIT_RECURSION_LIMIT	3
> +#else
>  #define XMIT_RECURSION_LIMIT	8
> +#endif

At least these tests (maybe more) fail with a limit this low:
  - selftests/net/forwarding/vxlan_symmetric.sh
  - selftests/net/forwarding/vxlan_symmetric_ipv6.sh
  - selftests/net/forwarding/vxlan_asymmetric.sh
  - selftests/net/forwarding/vxlan_asymmetric_ipv6.sh
  - selftests/net/test_bridge_backup_port.sh
  - selftests/net/test_vxlan_mdb.sh

Can in investigate what limit they need and whether their max is good
enough to avoid issues with KASAN?

Re: [PATCH net v3] net: reduce XMIT_RECURSION_LIMIT under KASAN

[kernel test robot]

Hello,

kernel test robot noticed "kselftests-bpf.net/forwarding fail" on:

commit: ef83ebe178d46ab0d26a906be5fcd654a488c730 ("[PATCH net v3] net: reduce XMIT_RECURSION_LIMIT under KASAN")
url: https://github.com/intel-lab-lkp/linux/commits/Tristan-Madani/net-reduce-XMIT_RECURSION_LIMIT-under-KASAN/20260728-072802
base: https://git.kernel.org/cgit/linux/kernel/git/davem/net.git bd0e9289e2642f6a5c54faad304ce0f41e926d22
patch link: https://lore.kernel.org/all/20260727200454.4048141-1-tristmd@gmail.com/
patch subject: [PATCH net v3] net: reduce XMIT_RECURSION_LIMIT under KASAN

in testcase: kselftests-bpf
version: 
with following parameters:

	group: net/forwarding
        failed cases:
		forwarding.custom_multipath_hash.sh
		forwarding.vxlan_asymmetric.sh
		forwarding.vxlan_asymmetric_ipv6.sh
		forwarding.vxlan_symmetric.sh
		forwarding.vxlan_symmetric_ipv6.sh


config: x86_64-rhel-9.4-bpf
compiler: gcc-14
test machine: 16 threads Intel(R) Core(TM) i7-13620H (Raptor Lake) with 32G memory

(please refer to attached dmesg/kmsg for entire log/backtrace)




If you fix the issue in a separate patch/commit (i.e. not just a new version of
the same patch/commit), kindly add following tags
| Reported-by: kernel test robot <yi1.lai@intel.com>
| Closes: https://lore.kernel.org/oe-lkp/202608121039.ca91f25a-lkp@intel.com


KERNEL SELFTESTS: linux_headers_dir is /usr/src/linux-headers-x86_64-rhel-9.4-bpf-ef83ebe178d46ab0d26a906be5fcd654a488c730
2026-08-04 22:51:54 sed -i s/default_timeout=45/default_timeout=300/ kselftest/runner.sh
2026-08-04 22:51:54 make -j16 TARGETS=net/forwarding run_tests
# timeout set to 0
# selftests: net/forwarding: custom_multipath_hash.sh
# TEST: ping                                                          [ OK ]
# TEST: ping6                                                         [ OK ]
# INFO: Running IPv4 custom multipath hash tests
# TEST: Multipath hash field: Source IP (balanced)                    [ OK ]
# INFO: Packets sent on path1 / path2: 6600 / 6001
# TEST: Multipath hash field: Source IP (unbalanced)                  [ OK ]
# INFO: Packets sent on path1 / path2: 0 / 12600
# TEST: Multipath hash field: Destination IP (balanced)               [ OK ]
# INFO: Packets sent on path1 / path2: 5950 / 6650
# TEST: Multipath hash field: Destination IP (unbalanced)             [ OK ]
# INFO: Packets sent on path1 / path2: 0 / 12600
# TEST: Multipath hash field: Source port (balanced)                  [ OK ]
# INFO: Packets sent on path1 / path2: 16505 / 16265
# TEST: Multipath hash field: Source port (unbalanced)                [ OK ]
# INFO: Packets sent on path1 / path2: 0 / 32771
# TEST: Multipath hash field: Destination port (balanced)             [ OK ]
# INFO: Packets sent on path1 / path2: 16504 / 16266
# TEST: Multipath hash field: Destination port (unbalanced)           [ OK ]
# INFO: Packets sent on path1 / path2: 32769 / 0
# INFO: Running IPv6 custom multipath hash tests
# TEST: Multipath hash field: Source IP (balanced)                    [ OK ]
# INFO: Packets sent on path1 / path2: 6102 / 6500
# TEST: Multipath hash field: Source IP (unbalanced)                  [ OK ]
# INFO: Packets sent on path1 / path2: 12600 / 0
# TEST: Multipath hash field: Destination IP (balanced)               [ OK ]
# INFO: Packets sent on path1 / path2: 6100 / 6500
# TEST: Multipath hash field: Destination IP (unbalanced)             [ OK ]
# INFO: Packets sent on path1 / path2: 12600 / 0
# TEST: Multipath hash field: Flowlabel (balanced)                    [FAIL]
# 	Expected traffic to be balanced, but it is not
# INFO: Packets sent on path1 / path2: 1 / 0
# TEST: Multipath hash field: Flowlabel (unbalanced)                  [ OK ]
# INFO: Packets sent on path1 / path2: 0 / 12600
# TEST: Multipath hash field: Source port (balanced)                  [ OK ]
# INFO: Packets sent on path1 / path2: 16422 / 16347
# TEST: Multipath hash field: Source port (unbalanced)                [ OK ]
# INFO: Packets sent on path1 / path2: 32771 / 0
# TEST: Multipath hash field: Destination port (balanced)             [ OK ]
# INFO: Packets sent on path1 / path2: 16422 / 16347
# TEST: Multipath hash field: Destination port (unbalanced)           [ OK ]
# INFO: Packets sent on path1 / path2: 32769 / 0
not ok 17 selftests: net/forwarding: custom_multipath_hash.sh # exit=1

# selftests: net/forwarding: vxlan_asymmetric.sh
# RTNETLINK answers: File exists
# RTNETLINK answers: File exists
# TEST: ping: local->local vid 10->vid 20                             [ OK ]
# TEST: ping: local->remote vid 10->vid 10                            [ OK ]
# TEST: ping: local->remote vid 20->vid 20                            [ OK ]
# TEST: ping: local->remote vid 10->vid 20                            [FAIL]
# TEST: ping: local->remote vid 20->vid 10                            [FAIL]
# INFO: deleting neighbours from vlan interfaces
# TEST: ping: local->local vid 10->vid 20                             [ OK ]
# TEST: ping: local->remote vid 10->vid 10                            [ OK ]
# TEST: ping: local->remote vid 20->vid 20                            [ OK ]
# TEST: ping: local->remote vid 10->vid 20                            [FAIL]
# TEST: ping: local->remote vid 20->vid 10                            [FAIL]

# selftests: net/forwarding: vxlan_asymmetric_ipv6.sh
# TEST: ping6: local->local vid 10->vid 20                            [ OK ]
# TEST: ping6: local->remote vid 10->vid 10                           [ OK ]
# TEST: ping6: local->remote vid 20->vid 20                           [ OK ]
# TEST: ping6: local->remote vid 10->vid 20                           [FAIL]
# TEST: ping6: local->remote vid 20->vid 10                           [FAIL]
# INFO: deleting neighbours from vlan interfaces
# TEST: ping6: local->local vid 10->vid 20                            [ OK ]
# TEST: ping6: local->remote vid 10->vid 10                           [ OK ]
# TEST: ping6: local->remote vid 20->vid 20                           [ OK ]
# TEST: ping6: local->remote vid 10->vid 20                           [FAIL]
# TEST: ping6: local->remote vid 20->vid 10                           [FAIL]
not ok 100 selftests: net/forwarding: vxlan_asymmetric_ipv6.sh # exit=1

# selftests: net/forwarding: vxlan_symmetric.sh
# RTNETLINK answers: File exists
# RTNETLINK answers: File exists
# TEST: ping: local->local vid 10->vid 20                             [ OK ]
# TEST: ping: local->remote vid 10->vid 10                            [ OK ]
# TEST: ping: local->remote vid 20->vid 20                            [ OK ]
# TEST: ping: local->remote vid 10->vid 20                            [FAIL]
# TEST: ping: local->remote vid 20->vid 10                            [FAIL]
not ok 111 selftests: net/forwarding: vxlan_symmetric.sh # exit=1

# timeout set to 0
# selftests: net/forwarding: vxlan_symmetric_ipv6.sh
# TEST: ping6: local->local vid 10->vid 20                            [ OK ]
# TEST: ping6: local->remote vid 10->vid 10                           [ OK ]
# TEST: ping6: local->remote vid 20->vid 20                           [ OK ]
# TEST: ping6: local->remote vid 10->vid 20                           [FAIL]
# TEST: ping6: local->remote vid 20->vid 10                           [FAIL]
not ok 112 selftests: net/forwarding: vxlan_symmetric_ipv6.sh # exit=1

The kernel config and materials to reproduce are available at:
https://download.01.org/0day-ci/archive/20260812/202608121039.ca91f25a-lkp@intel.com



-- 
0-DAY CI Kernel Test Service
https://github.com/intel/lkp-tests/wiki

[PATCH net v4] net: reduce XMIT_RECURSION_LIMIT under KASAN

[Tristan Madani]

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

Re: [PATCH net v4] net: reduce XMIT_RECURSION_LIMIT under KASAN

[netdev-bot+sashiko]

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

Re: [PATCH net v4] net: reduce XMIT_RECURSION_LIMIT under KASAN

[patchwork-bot+netdevbpf]

Hello:

This patch was applied to netdev/net-next.git (main)
by Jakub Kicinski <kuba@kernel.org>:

On Wed,  2 Sep 2026 12:30:40 +0000 you wrote:
> 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.
> 
> [...]

Here is the summary with links:
  - [net,v4] net: reduce XMIT_RECURSION_LIMIT under KASAN
    https://git.kernel.org/netdev/net-next/c/7f1de03e3103

You are awesome, thank you!
-- 
Deet-doot-dot, I am a bot.
https://korg.docs.kernel.org/patchwork/pwbot.html