public inbox for netdev@vger.kernel.org
 help / color / mirror / Atom feed
From: Paolo Abeni <pabeni@redhat.com>
To: bestswngs@gmail.com, security@kernel.org
Cc: edumazet@google.com, davem@davemloft.net, kuba@kernel.org,
	horms@kernel.org, netdev@vger.kernel.org,
	linux-kernel@vger.kernel.org, xmei5@asu.edu
Subject: Re: [PATCH net v2] net: add xmit recursion limit to tunnel drivers
Date: Thu, 5 Mar 2026 15:34:12 +0100	[thread overview]
Message-ID: <a8a81818-459f-4c09-8448-31a191f7b2bb@redhat.com> (raw)
In-Reply-To: <20260303164326.1803916-2-bestswngs@gmail.com>

On 3/3/26 5:43 PM, bestswngs@gmail.com wrote:
> From: Weiming Shi <bestswngs@gmail.com>
> 
> __dev_queue_xmit() has two transmit code paths depending on whether the
> device has a qdisc attached:
> 
>  1. Qdisc path (q->enqueue): calls __dev_xmit_skb()
>  2. No-qdisc path: calls dev_hard_start_xmit() directly
> 
> Commit 745e20f1b626 ("net: add a recursion limit in xmit path") added
> recursion protection to the no-qdisc path via dev_xmit_recursion()
> check and dev_xmit_recursion_inc()/dec() tracking. However, the qdisc
> path performs no recursion depth checking at all.
> 
> This allows unbounded recursion through qdisc-attached devices. For
> example, a bond interface in broadcast mode with gretap slaves whose
> remote endpoints route back through the bond creates an infinite
> transmit loop that exhausts the kernel stack:
> 
>  BUG: KASAN: stack-out-of-bounds in blake2s.constprop.0+0xe7/0x160
>  Write of size 32 at addr ffff88810033fed0 by task kworker/0:1/11
>  Workqueue: mld mld_ifc_work
>  Call Trace:
>   <TASK>
>   __build_flow_key.constprop.0 (net/ipv4/route.c:515)
>   ip_rt_update_pmtu (net/ipv4/route.c:1073)
>   iptunnel_xmit (net/ipv4/ip_tunnel_core.c:84)
>   ip_tunnel_xmit (net/ipv4/ip_tunnel.c:847)
>   gre_tap_xmit (net/ipv4/ip_gre.c:779)
>   dev_hard_start_xmit (net/core/dev.c:3887)
>   sch_direct_xmit (net/sched/sch_generic.c:347)
>   __dev_queue_xmit (net/core/dev.c:4802)
>   bond_dev_queue_xmit (drivers/net/bonding/bond_main.c:312)
>   bond_xmit_broadcast (drivers/net/bonding/bond_main.c:5279)
>   bond_start_xmit (drivers/net/bonding/bond_main.c:5530)
>   dev_hard_start_xmit (net/core/dev.c:3887)
>   __dev_queue_xmit (net/core/dev.c:4841)
>   ip_finish_output2 (net/ipv4/ip_output.c:237)
>   ip_output (net/ipv4/ip_output.c:438)
>   iptunnel_xmit (net/ipv4/ip_tunnel_core.c:86)
>   gre_tap_xmit (net/ipv4/ip_gre.c:779)
>   dev_hard_start_xmit (net/core/dev.c:3887)
>   sch_direct_xmit (net/sched/sch_generic.c:347)
>   __dev_queue_xmit (net/core/dev.c:4802)
>   bond_dev_queue_xmit (drivers/net/bonding/bond_main.c:312)
>   bond_xmit_broadcast (drivers/net/bonding/bond_main.c:5279)
>   bond_start_xmit (drivers/net/bonding/bond_main.c:5530)
>   dev_hard_start_xmit (net/core/dev.c:3887)
>   __dev_queue_xmit (net/core/dev.c:4841)
>   ip_finish_output2 (net/ipv4/ip_output.c:237)
>   ip_output (net/ipv4/ip_output.c:438)
>   iptunnel_xmit (net/ipv4/ip_tunnel_core.c:86)
>   ip_tunnel_xmit (net/ipv4/ip_tunnel.c:847)
>   gre_tap_xmit (net/ipv4/ip_gre.c:779)
>   dev_hard_start_xmit (net/core/dev.c:3887)
>   sch_direct_xmit (net/sched/sch_generic.c:347)
>   __dev_queue_xmit (net/core/dev.c:4802)
>   bond_dev_queue_xmit (drivers/net/bonding/bond_main.c:312)
>   bond_xmit_broadcast (drivers/net/bonding/bond_main.c:5279)
>   bond_start_xmit (drivers/net/bonding/bond_main.c:5530)
>   dev_hard_start_xmit (net/core/dev.c:3887)
>   __dev_queue_xmit (net/core/dev.c:4841)
>   mld_sendpack
>   mld_ifc_work
>   process_one_work
>   worker_thread
>   </TASK>
> 
> Rather than adding an expensive recursion check to the common qdisc
> fast path, add recursion detection directly in tunnel drivers where
> route lookups can create these loops, as suggested by Eric Dumazet.
> 
> Use a lower limit (IP_TUNNEL_RECURSION_LIMIT=4) than XMIT_RECURSION_LIMIT
> (8) because each tunnel recursion level involves route lookups and full
> IP output processing, consuming significantly more stack per level.
> 
> Move dev_xmit_recursion helpers from the private net/core/dev.h header
> to the public include/linux/netdevice.h so tunnel drivers can use them.
> 
> Fixes: 745e20f1b626 ("net: add a recursion limit in xmit path")
> Reported-by: Xiang Mei <xmei5@asu.edu>
> Signed-off-by: Weiming Shi <bestswngs@gmail.com>
> ---
> v2:
>   - Move recursion check from qdisc path to tunnel drivers (Eric Dumazet)
>   - Add IPv6 tunnel (ip6_tunnel) coverage
>   - Use lower recursion limit (4) for tunnel-specific stack consumption
> 
>  include/linux/netdevice.h | 32 ++++++++++++++++++++++++++++++++
>  include/net/ip_tunnels.h  |  7 +++++++
>  net/core/dev.h            | 34 ----------------------------------
>  net/ipv4/ip_tunnel.c      | 10 ++++++++++
>  net/ipv6/ip6_tunnel.c     | 10 ++++++++++
>  5 files changed, 59 insertions(+), 34 deletions(-)
> 
> diff --git a/include/linux/netdevice.h b/include/linux/netdevice.h
> index d4e6e00bb90a..1a4d2542dbab 100644
> --- a/include/linux/netdevice.h
> +++ b/include/linux/netdevice.h
> @@ -3576,17 +3576,49 @@ struct page_pool_bh {
>  };
>  DECLARE_PER_CPU(struct page_pool_bh, system_page_pool);
>  
> +#define XMIT_RECURSION_LIMIT	8
> +
>  #ifndef CONFIG_PREEMPT_RT
>  static inline int dev_recursion_level(void)
>  {
>  	return this_cpu_read(softnet_data.xmit.recursion);
>  }
> +
> +static inline bool dev_xmit_recursion(void)
> +{
> +	return unlikely(__this_cpu_read(softnet_data.xmit.recursion) >
> +			XMIT_RECURSION_LIMIT);
> +}
> +
> +static inline void dev_xmit_recursion_inc(void)
> +{
> +	__this_cpu_inc(softnet_data.xmit.recursion);
> +}
> +
> +static inline void dev_xmit_recursion_dec(void)
> +{
> +	__this_cpu_dec(softnet_data.xmit.recursion);
> +}
>  #else
>  static inline int dev_recursion_level(void)
>  {
>  	return current->net_xmit.recursion;
>  }
>  
> +static inline bool dev_xmit_recursion(void)
> +{
> +	return unlikely(current->net_xmit.recursion > XMIT_RECURSION_LIMIT);
> +}
> +
> +static inline void dev_xmit_recursion_inc(void)
> +{
> +	current->net_xmit.recursion++;
> +}
> +
> +static inline void dev_xmit_recursion_dec(void)
> +{
> +	current->net_xmit.recursion--;
> +}
>  #endif
>  
>  void __netif_schedule(struct Qdisc *q);
> diff --git a/include/net/ip_tunnels.h b/include/net/ip_tunnels.h
> index 4021e6a73e32..80662f812080 100644
> --- a/include/net/ip_tunnels.h
> +++ b/include/net/ip_tunnels.h
> @@ -27,6 +27,13 @@
>  #include <net/ip6_route.h>
>  #endif
>  
> +/* 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	4
> +
>  /* Keep error state on tunnel for 30 sec */
>  #define IPTUNNEL_ERR_TIMEO	(30*HZ)
>  
> diff --git a/net/core/dev.h b/net/core/dev.h
> index 98793a738f43..ec974b3c42d9 100644
> --- a/net/core/dev.h
> +++ b/net/core/dev.h
> @@ -366,40 +366,6 @@ static inline void napi_assert_will_not_race(const struct napi_struct *napi)
>  
>  void kick_defer_list_purge(unsigned int cpu);
>  
> -#define XMIT_RECURSION_LIMIT	8
> -
> -#ifndef CONFIG_PREEMPT_RT
> -static inline bool dev_xmit_recursion(void)
> -{
> -	return unlikely(__this_cpu_read(softnet_data.xmit.recursion) >
> -			XMIT_RECURSION_LIMIT);
> -}
> -
> -static inline void dev_xmit_recursion_inc(void)
> -{
> -	__this_cpu_inc(softnet_data.xmit.recursion);
> -}
> -
> -static inline void dev_xmit_recursion_dec(void)
> -{
> -	__this_cpu_dec(softnet_data.xmit.recursion);
> -}
> -#else
> -static inline bool dev_xmit_recursion(void)
> -{
> -	return unlikely(current->net_xmit.recursion > XMIT_RECURSION_LIMIT);
> -}
> -
> -static inline void dev_xmit_recursion_inc(void)
> -{
> -	current->net_xmit.recursion++;
> -}
> -
> -static inline void dev_xmit_recursion_dec(void)
> -{
> -	current->net_xmit.recursion--;
> -}
> -#endif
>  
>  int dev_set_hwtstamp_phylib(struct net_device *dev,
>  			    struct kernel_hwtstamp_config *cfg,
> diff --git a/net/ipv4/ip_tunnel.c b/net/ipv4/ip_tunnel.c
> index 50d0f5fe4e4c..39822e845a06 100644
> --- a/net/ipv4/ip_tunnel.c
> +++ b/net/ipv4/ip_tunnel.c
> @@ -683,6 +683,14 @@ void ip_tunnel_xmit(struct sk_buff *skb, struct net_device *dev,
>  	__be32 dst;
>  	__be16 df;
>  
> +	if (dev_recursion_level() > IP_TUNNEL_RECURSION_LIMIT) {
> +		net_crit_ratelimited("Dead loop on virtual device %s, fix it urgently!\n",
> +				     dev->name);
> +		DEV_STATS_INC(dev, tx_errors);
> +		kfree_skb(skb);
> +		return;
> +	}
> +
>  	inner_iph = (const struct iphdr *)skb_inner_network_header(skb);
>  	connected = (tunnel->parms.iph.daddr != 0);
>  	payload_protocol = skb_protocol(skb, true);
> @@ -842,8 +850,10 @@ void ip_tunnel_xmit(struct sk_buff *skb, struct net_device *dev,
>  
>  	ip_tunnel_adj_headroom(dev, max_headroom);
>  
> +	dev_xmit_recursion_inc();
>  	iptunnel_xmit(NULL, rt, skb, fl4.saddr, fl4.daddr, protocol, tos, ttl,
>  		      df, !net_eq(tunnel->net, dev_net(dev)), 0);

I think this check should go in iptunnel_xmit(), or UDP tunnels will
remain unprotected.

Same thing for the IPv6 case.

> +	dev_xmit_recursion_dec();
>  	return;
>  
>  #if IS_ENABLED(CONFIG_IPV6)
> diff --git a/net/ipv6/ip6_tunnel.c b/net/ipv6/ip6_tunnel.c
> index 4c29aa94e86e..55bedd5cd656 100644
> --- a/net/ipv6/ip6_tunnel.c
> +++ b/net/ipv6/ip6_tunnel.c
> @@ -1101,6 +1101,14 @@ int ip6_tnl_xmit(struct sk_buff *skb, struct net_device *dev, __u8 dsfield,
>  	u8 hop_limit;
>  	int err = -1;
>  
> +	if (dev_recursion_level() > IP_TUNNEL_RECURSION_LIMIT) {
> +		net_crit_ratelimited("Dead loop on virtual device %s, fix it urgently!\n",
> +				     dev->name);
> +		DEV_STATS_INC(dev, tx_errors);
> +		kfree_skb(skb);
> +		return -1;

I think an standard error code is expected here. Possibly -ELOOP?

/P


  parent reply	other threads:[~2026-03-05 14:34 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-03-03 16:43 [PATCH net v2] net: add xmit recursion limit to tunnel drivers bestswngs
2026-03-05 14:23 ` [net,v2] " Paolo Abeni
2026-03-05 14:34 ` Paolo Abeni [this message]
2026-03-05 17:08   ` [PATCH net v2] " Weiming Shi

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=a8a81818-459f-4c09-8448-31a191f7b2bb@redhat.com \
    --to=pabeni@redhat.com \
    --cc=bestswngs@gmail.com \
    --cc=davem@davemloft.net \
    --cc=edumazet@google.com \
    --cc=horms@kernel.org \
    --cc=kuba@kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=netdev@vger.kernel.org \
    --cc=security@kernel.org \
    --cc=xmei5@asu.edu \
    /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