From: Tristan Madani <tristmd@gmail.com>
To: netdev@vger.kernel.org
Cc: davem@davemloft.net, edumazet@google.com, kuba@kernel.org,
pabeni@redhat.com, andrew+netdev@lunn.ch, horms@kernel.org,
maheshb@google.com, stable@vger.kernel.org,
linux-kernel@vger.kernel.org,
Tristan Madani <tristan@talencesecurity.com>
Subject: [PATCH net v2] net: reduce XMIT_RECURSION_LIMIT under KASAN
Date: Sat, 11 Jul 2026 20:47:00 +0000 [thread overview]
Message-ID: <20260711204700.1760374-1-tristmd@gmail.com> (raw)
In-Reply-To: <20260711134732.1385563-1-tristmd@gmail.com>
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>
---
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.
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
prev parent reply other threads:[~2026-07-11 20:47 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-07-11 13:47 [PATCH net] ipvlan: add xmit recursion protection Tristan Madani
2026-07-11 14:00 ` Eric Dumazet
2026-07-11 20:47 ` Tristan Madani [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20260711204700.1760374-1-tristmd@gmail.com \
--to=tristmd@gmail.com \
--cc=andrew+netdev@lunn.ch \
--cc=davem@davemloft.net \
--cc=edumazet@google.com \
--cc=horms@kernel.org \
--cc=kuba@kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=maheshb@google.com \
--cc=netdev@vger.kernel.org \
--cc=pabeni@redhat.com \
--cc=stable@vger.kernel.org \
--cc=tristan@talencesecurity.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox