* [PATCH net v3] net: reduce XMIT_RECURSION_LIMIT under KASAN
@ 2026-07-27 20:04 Tristan Madani
2026-07-27 23:24 ` Jakub Kicinski
` (2 more replies)
0 siblings, 3 replies; 6+ messages in thread
From: Tristan Madani @ 2026-07-27 20:04 UTC (permalink / raw)
To: netdev
Cc: davem, edumazet, kuba, pabeni, andrew+netdev, horms, maheshb,
stable, linux-kernel, 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
^ permalink raw reply related [flat|nested] 6+ messages in thread* Re: [PATCH net v3] net: reduce XMIT_RECURSION_LIMIT under KASAN 2026-07-27 20:04 [PATCH net v3] net: reduce XMIT_RECURSION_LIMIT under KASAN Tristan Madani @ 2026-07-27 23:24 ` Jakub Kicinski 2026-08-12 8:55 ` kernel test robot 2026-09-02 12:30 ` [PATCH net v4] " Tristan Madani 2 siblings, 0 replies; 6+ messages in thread From: Jakub Kicinski @ 2026-07-27 23:24 UTC (permalink / raw) To: Tristan Madani Cc: netdev, davem, edumazet, pabeni, andrew+netdev, horms, maheshb, stable, linux-kernel, Tristan Madani 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? ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [PATCH net v3] net: reduce XMIT_RECURSION_LIMIT under KASAN 2026-07-27 20:04 [PATCH net v3] net: reduce XMIT_RECURSION_LIMIT under KASAN Tristan Madani 2026-07-27 23:24 ` Jakub Kicinski @ 2026-08-12 8:55 ` kernel test robot 2026-09-02 12:30 ` [PATCH net v4] " Tristan Madani 2 siblings, 0 replies; 6+ messages in thread From: kernel test robot @ 2026-08-12 8:55 UTC (permalink / raw) To: Tristan Madani Cc: oe-lkp, lkp, netdev, davem, edumazet, kuba, pabeni, andrew+netdev, horms, maheshb, stable, linux-kernel, Tristan Madani, yi1.lai 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 ^ permalink raw reply [flat|nested] 6+ messages in thread
* [PATCH net v4] net: reduce XMIT_RECURSION_LIMIT under KASAN 2026-07-27 20:04 [PATCH net v3] net: reduce XMIT_RECURSION_LIMIT under KASAN Tristan Madani 2026-07-27 23:24 ` Jakub Kicinski 2026-08-12 8:55 ` kernel test robot @ 2026-09-02 12:30 ` Tristan Madani 2026-09-04 0:32 ` netdev-bot+sashiko 2026-09-04 23:10 ` patchwork-bot+netdevbpf 2 siblings, 2 replies; 6+ messages in thread From: Tristan Madani @ 2026-09-02 12:30 UTC (permalink / raw) To: Andrew Lunn, David S . Miller, Eric Dumazet, Jakub Kicinski, Paolo Abeni Cc: Simon Horman, Mahesh Bandewar, netdev, linux-kernel, stable, 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 ^ permalink raw reply related [flat|nested] 6+ messages in thread
* Re: [PATCH net v4] net: reduce XMIT_RECURSION_LIMIT under KASAN 2026-09-02 12:30 ` [PATCH net v4] " Tristan Madani @ 2026-09-04 0:32 ` netdev-bot+sashiko 2026-09-04 23:10 ` patchwork-bot+netdevbpf 1 sibling, 0 replies; 6+ messages in thread From: netdev-bot+sashiko @ 2026-09-04 0:32 UTC (permalink / raw) To: tristmd Cc: andrew+netdev, davem, edumazet, kuba, pabeni, horms, maheshb, netdev, linux-kernel, stable, tristan 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 ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [PATCH net v4] net: reduce XMIT_RECURSION_LIMIT under KASAN 2026-09-02 12:30 ` [PATCH net v4] " Tristan Madani 2026-09-04 0:32 ` netdev-bot+sashiko @ 2026-09-04 23:10 ` patchwork-bot+netdevbpf 1 sibling, 0 replies; 6+ messages in thread From: patchwork-bot+netdevbpf @ 2026-09-04 23:10 UTC (permalink / raw) To: Tristan Madani Cc: andrew+netdev, davem, edumazet, kuba, pabeni, horms, maheshb, netdev, linux-kernel, stable, tristan 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 ^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2026-09-04 23:11 UTC | newest] Thread overview: 6+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2026-07-27 20:04 [PATCH net v3] net: reduce XMIT_RECURSION_LIMIT under KASAN Tristan Madani 2026-07-27 23:24 ` Jakub Kicinski 2026-08-12 8:55 ` kernel test robot 2026-09-02 12:30 ` [PATCH net v4] " Tristan Madani 2026-09-04 0:32 ` netdev-bot+sashiko 2026-09-04 23:10 ` patchwork-bot+netdevbpf
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox