[PATCH linux-6.1.y linux-6.6.y linux-6.12.y 0/1] ndisc: backport ndisc_send_redirect() cleanup

[PATCH linux-6.1.y linux-6.6.y linux-6.12.y 0/1] ndisc: backport ndisc_send_redirect() cleanup

[Li Xiasong]

Please consider backporting upstream 0784d83df3bf to 6.1.y,
6.6.y and 6.12.y. It looks like the missing prerequisite for
dbc3791e3b24 ("net: do not send ICMP/NDISC Redirects when peer
allocation fails") already queued on these trees.

dbc3791e3b24 adds "if (!peer) goto release;" inside
rcu_read_lock()/rcu_read_unlock() in ndisc_send_redirect(),
which seems to leak the read lock on the NULL-peer path on
these trees. This cleanup drops the pair (callers already hold
rcu_read_lock()), so the leak would go away.

The patch below is against 6.12.y; the identical change applies
to 6.1.y and 6.6.y.

Eric Dumazet (1):
  ndisc: ndisc_send_redirect() cleanup

 net/ipv6/ndisc.c | 8 +++-----
 1 file changed, 3 insertions(+), 5 deletions(-)

-- 
2.34.1

[PATCH linux-6.1.y linux-6.6.y linux-6.12.y 1/1] ndisc: ndisc_send_redirect() cleanup

[Li Xiasong]

From: Eric Dumazet <edumazet@google.com>

[ Upstream commit 0784d83df3bfc977c13252a0599be924f0afa68d ]

ndisc_send_redirect() is always called under rcu_read_lock().

It can use dev_net_rcu() and avoid one redundant
rcu_read_lock()/rcu_read_unlock() pair.

Signed-off-by: Eric Dumazet <edumazet@google.com>
Reviewed-by: David Ahern <dsahern@kernel.org>
Link: https://patch.msgid.link/20250214140705.2105890-1-edumazet@google.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Signed-off-by: Li Xiasong <lixiasong1@huawei.com>
---
 net/ipv6/ndisc.c | 8 +++-----
 1 file changed, 3 insertions(+), 5 deletions(-)

diff --git a/net/ipv6/ndisc.c b/net/ipv6/ndisc.c
index 585a9135cf26..7d703a66c0a3 100644
--- a/net/ipv6/ndisc.c
+++ b/net/ipv6/ndisc.c
@@ -1671,7 +1671,7 @@ static void ndisc_fill_redirect_hdr_option(struct sk_buff *skb,
 void ndisc_send_redirect(struct sk_buff *skb, const struct in6_addr *target)
 {
 	struct net_device *dev = skb->dev;
-	struct net *net = dev_net(dev);
+	struct net *net = dev_net_rcu(dev);
 	struct sock *sk = net->ipv6.ndisc_sk;
 	int optlen = 0;
 	struct inet_peer *peer;
@@ -1686,8 +1686,8 @@ void ndisc_send_redirect(struct sk_buff *skb, const struct in6_addr *target)
 	   ops_data_buf[NDISC_OPS_REDIRECT_DATA_SPACE], *ops_data = NULL;
 	bool ret;
 
-	if (netif_is_l3_master(skb->dev)) {
-		dev = dev_get_by_index_rcu(dev_net(skb->dev), IPCB(skb)->iif);
+	if (netif_is_l3_master(dev)) {
+		dev = dev_get_by_index_rcu(net, IPCB(skb)->iif);
 		if (!dev)
 			return;
 	}
@@ -1725,12 +1725,10 @@ void ndisc_send_redirect(struct sk_buff *skb, const struct in6_addr *target)
 		goto release;
 	}
 
-	rcu_read_lock();
 	peer = inet_getpeer_v6(net->ipv6.peers, &ipv6_hdr(skb)->saddr);
 	if (!peer)
 		goto release;
 	ret = inet_peer_xrlim_allow(peer, 1*HZ);
-	rcu_read_unlock();
 
 	if (!ret)
 		goto release;
-- 
2.34.1

Re: [PATCH linux-6.1.y linux-6.6.y linux-6.12.y 0/1] ndisc: backport ndisc_send_redirect() cleanup

[Greg KH]

On Mon, Aug 24, 2026 at 09:38:51PM +0800, Li Xiasong wrote:
> Please consider backporting upstream 0784d83df3bf to 6.1.y,
> 6.6.y and 6.12.y. It looks like the missing prerequisite for
> dbc3791e3b24 ("net: do not send ICMP/NDISC Redirects when peer
> allocation fails") already queued on these trees.
> 
> dbc3791e3b24 adds "if (!peer) goto release;" inside
> rcu_read_lock()/rcu_read_unlock() in ndisc_send_redirect(),
> which seems to leak the read lock on the NULL-peer path on
> these trees. This cleanup drops the pair (callers already hold
> rcu_read_lock()), so the leak would go away.
> 
> The patch below is against 6.12.y; the identical change applies
> to 6.1.y and 6.6.y.

Thanks for noticing this and the backport.

Re: [PATCH linux-6.1.y linux-6.6.y linux-6.12.y 0/1] ndisc: backport ndisc_send_redirect() cleanup

[Sasha Levin]

On Mon, Aug 24, 2026 at 09:38:51PM +0800, Li Xiasong wrote:
> dbc3791e3b24 adds "if (!peer) goto release;" inside
> rcu_read_lock()/rcu_read_unlock() in ndisc_send_redirect(),
> which seems to leak the read lock on the NULL-peer path on
> these trees. This cleanup drops the pair (callers already hold
> rcu_read_lock()), so the leak would go away.

Correct, and confirmed here - ip6_forward() already wraps the call in
rcu_read_lock() on all three trees.

Queued for 6.12, 6.6 and 6.1, thanks.

-- 
Thanks,
Sasha