From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-wr1-f41.google.com (mail-wr1-f41.google.com [209.85.221.41]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 94DC431F983 for ; Mon, 27 Jul 2026 20:04:58 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.221.41 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1785182700; cv=none; b=vGoNr6/CPfXRIw7MB15+zXEwb0wY14I8ainUg9lLCPrR+750FjtZB5MrlbFFhADDihe00OrNImeYku+B3o3Z2qYJwQ9OmiWfd/2CxY3a8zQ2VXTunG+t4YVddkGGV3IgoPgC8UCH+RtU8PMie7FmYK9DqeZQ6tS62YaQ8Yv2IpQ= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1785182700; c=relaxed/simple; bh=vKQJ7QNJv+uZz9x0zSIk21ClMOvdIiAE3tig64AC2Ms=; h=From:To:Cc:Subject:Date:Message-ID:MIME-Version; b=CYMRVrsXTJW5px5sHgf0Ff1DXUQVWs9kyW67zuAIRY2V7Jj1t1oOYqqcC2EgplwI5bpPwF1ARHsHeP6FlfCwJFRGOcd7FQ0uPJw/wYPcd5/T89g9K4yqJvmAhqCSPOwI9t2hU51u/W+CmGK+Rc3Oh3Mzb71G+mYehho9+RaZ2I8= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com; spf=pass smtp.mailfrom=gmail.com; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b=ca10de42; arc=none smtp.client-ip=209.85.221.41 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=gmail.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b="ca10de42" Received: by mail-wr1-f41.google.com with SMTP id ffacd0b85a97d-47f96c5b722so1784094f8f.0 for ; Mon, 27 Jul 2026 13:04:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1785182697; x=1785787497; darn=vger.kernel.org; h=content-transfer-encoding:mime-version:message-id:date:subject:cc :to:from:from:to:cc:subject:date:message-id:reply-to:content-type; bh=ZaCjvFlh04tSbrzp8Qm4VrJ+XEIKD0uan3d5oYYxA9I=; b=ca10de4256robnFq86NIEIxsRDK+qjrxo4Z9mHKXeAfywqIeJVz673aPVdNZUGtT9j 0xfFIw+AJcjPi4PNEYJhRPT+om/BnNeTq4NvUJBqg+ywNs7A77kk/owLTu/RubN90DRP AiEdUek5uHJdZxcZwN2mFchKkZyfrtkKdDSBiEVA0EkC81kEoF4zTSMBe0Q43dJRvWHV Q8k0JpnNlrP1Z4OQdN08X5HPqri8qeRUOX34Sn4+fZB4cwyFY1ishYYvqCRQ4hz1y5zj LigGKEFuu64FM/bBEwSiGluYN/Wdz73sZOpcuF9LI3+7OvTBxV53OlwnXzQkYiRMNNW9 gEeg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1785182697; x=1785787497; h=content-transfer-encoding:mime-version:message-id:date:subject:cc :to:from:x-gm-gg:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to:content-type; bh=ZaCjvFlh04tSbrzp8Qm4VrJ+XEIKD0uan3d5oYYxA9I=; b=CMDA2L8lKPT3sjSR2gMNCTl/Kah6xQB+dxIliE4KjwJEgwtQykmvVYGi4Dklz1eJvo W3PZKQcoAJ5eW/5GEX7uOhKQXtMKWl9exrxvPOFK7skS+BlVOSqKGT5lHd/4yPmVpqP/ 4LQ1MMQ+ggxK0yFmm9wYmHAwaC6GhdvLMjsKgDHVBqfoqMqwWBHwLE8MFCRPNqMMs6QG qfHRhyk3xUtVOCEj6sPyjLv761gi0ikKpEAJBNhtdOobbIbWjco7pGgMpHKre2WOX751 rWb9uK+EolDi3+kgmDbXzrM29s/UObPkaZfchh3Au9y8IdnuznYF1Y5rFp85gPH9ZOBU FGbQ== X-Forwarded-Encrypted: i=1; AHgh+RqKl9IY+iUKajAMA2fxqeTx78VdFAz/RQW3e7CpmXtdnzcHVd4hmsuUd9+OTVgf5eM96AefC5ziyAY1EGg=@vger.kernel.org X-Gm-Message-State: AOJu0Yy/jVA1ioA40N//RymOqMdMNBsSFBnef9uxZB+hVQ9RZHIkeGGE HShoLFv7rCOlEjGK4PbfDAGR1Wq5uezMyUl4U24fpvhbRMLZYocDEvM= X-Gm-Gg: AR+sD11S4w+lneJxkxJVoFnIId7c2FOPEpKUxO1YpG5uQjPoo6hS3onax7rRiExGGOJ zQPUwfhrkiaUUvJ24Dx/8EZ0nVOwy0oy/IIfzUNuqSPQmug2tY8sYM+zmDwhfL1muPMyYta3tSY Repw0FqNuNrsACY6+ghRy2BdM749UMcRETQribz+SSVKSwR6QP4i795LsV18LfgHZeQ5hEjaPB1 3qijm0WiDkYqpFv1VPUJroPdnZyq/WaFlQMyCp0KkU/Z5FKyTTrV/ynLqydDPvexXvqAzt4XTeF W0FlI9qCMNkz8LiQdjOBWW/+Sf3r7JC3QfCBDVAfoQvI771tiGN4h8TPVPzO9h8M/H18vZdSAxb HZRvgHMxbu37MDRFvJr9YzwegXlDzC5NQnwsQoamzXyMfb6n/eprq8jkaDV870vIMpgYwI0L6dH EKeaWqVBs7uU+QC4YQgf6d3khXLdDByx7bkaPP2TALoQ== X-Received: by 2002:a05:600c:6dd5:b0:493:e583:7053 with SMTP id 5b1f17b1804b1-496c4fe26d3mr3319875e9.35.1785182696309; Mon, 27 Jul 2026 13:04:56 -0700 (PDT) Received: from debian.. ([2001:41d0:303:db6b::]) by smtp.gmail.com with ESMTPSA id 5b1f17b1804b1-496c46160dfsm18406235e9.10.2026.07.27.13.04.55 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 27 Jul 2026 13:04:55 -0700 (PDT) From: Tristan Madani 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 Subject: [PATCH net v3] net: reduce XMIT_RECURSION_LIMIT under KASAN Date: Mon, 27 Jul 2026 20:04:54 +0000 Message-ID: <20260727200454.4048141-1-tristmd@gmail.com> X-Mailer: git-send-email 2.47.3 Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: 8bit From: Tristan Madani 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 --- 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