[PATCH net 1/2] ipv6: fix possible infinite loop in rt6_fill_node()

[PATCH net 1/2] ipv6: fix possible infinite loop in rt6_fill_node()

[Jiayuan Chen]

Sashiko reported this issue [1]. Apply the same fix as
commit f8d8ce1b515a ("ipv6: fix possible infinite loop in fib6_info_uses_dev()").

Writers holding tb6_lock can list_del_rcu(&rt->fib6_siblings)
without waiting for RCU readers; rt->fib6_siblings.next then still
points into the old ring and this softirq-side walker never reaches
&rt->fib6_siblings, causing a CPU stall. fib6_purge_rt() always
WRITE_ONCE()s rt->fib6_nsiblings to 0 before list_del_rcu(), so an
inside-loop check is a reliable detach signal.

[1] https://sashiko.dev/#/patchset/20260526020227.4857-1-jiayuan.chen%40linux.dev

Fixes: d9ccb18f83ea ("ipv6: Fix soft lockups in fib6_select_path under high next hop churn")
Signed-off-by: Jiayuan Chen <jiayuan.chen@linux.dev>
---
 net/ipv6/route.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/net/ipv6/route.c b/net/ipv6/route.c
index b106e5fef9cb..dad416fdc585 100644
--- a/net/ipv6/route.c
+++ b/net/ipv6/route.c
@@ -5902,6 +5902,8 @@ static int rt6_fill_node(struct net *net, struct sk_buff *skb,
 
 				goto nla_put_failure;
 			}
+			if (!READ_ONCE(rt->fib6_nsiblings))
+				break;
 		}
 
 		rcu_read_unlock();
-- 
2.43.0

[PATCH net 2/2] ipv6: fix possible infinite loop in fib6_select_path()

[Jiayuan Chen]

Found while auditing the same pattern Sashiko reported in
rt6_fill_node() [1]. Apply the same fix as
commit f8d8ce1b515a ("ipv6: fix possible infinite loop in fib6_info_uses_dev()").

Writers holding tb6_lock can list_del_rcu(&first->fib6_siblings)
without waiting for RCU readers; first->fib6_siblings.next then
still points into the old ring and this softirq-side walker never
reaches &first->fib6_siblings as its terminator. fib6_purge_rt()
always WRITE_ONCE()s first->fib6_nsiblings to 0 before
list_del_rcu(), so an inside-loop check is a reliable detach signal.

[1] https://sashiko.dev/#/patchset/20260526020227.4857-1-jiayuan.chen%40linux.dev

Fixes: d9ccb18f83ea ("ipv6: Fix soft lockups in fib6_select_path under high next hop churn")
Signed-off-by: Jiayuan Chen <jiayuan.chen@linux.dev>
---
 net/ipv6/route.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/net/ipv6/route.c b/net/ipv6/route.c
index dad416fdc585..636f0120d7e3 100644
--- a/net/ipv6/route.c
+++ b/net/ipv6/route.c
@@ -481,6 +481,9 @@ void fib6_select_path(const struct net *net, struct fib6_result *res,
 		const struct fib6_nh *nh = sibling->fib6_nh;
 		int nh_upper_bound;
 
+		if (!READ_ONCE(first->fib6_nsiblings))
+			break;
+
 		nh_upper_bound = atomic_read(&nh->fib_nh_upper_bound);
 		if (hash > nh_upper_bound)
 			continue;
-- 
2.43.0

Re: [PATCH net 2/2] ipv6: fix possible infinite loop in fib6_select_path()

[Ido Schimmel]

On Wed, May 27, 2026 at 01:31:31PM +0800, Jiayuan Chen wrote:
> Found while auditing the same pattern Sashiko reported in
> rt6_fill_node() [1]. Apply the same fix as
> commit f8d8ce1b515a ("ipv6: fix possible infinite loop in fib6_info_uses_dev()").
> 
> Writers holding tb6_lock can list_del_rcu(&first->fib6_siblings)
> without waiting for RCU readers; first->fib6_siblings.next then
> still points into the old ring and this softirq-side walker never
> reaches &first->fib6_siblings as its terminator. fib6_purge_rt()
> always WRITE_ONCE()s first->fib6_nsiblings to 0 before
> list_del_rcu(), so an inside-loop check is a reliable detach signal.
> 
> [1] https://sashiko.dev/#/patchset/20260526020227.4857-1-jiayuan.chen%40linux.dev
> 
> Fixes: d9ccb18f83ea ("ipv6: Fix soft lockups in fib6_select_path under high next hop churn")
> Signed-off-by: Jiayuan Chen <jiayuan.chen@linux.dev>

Reviewed-by: Ido Schimmel <idosch@nvidia.com>

Re: [PATCH net 1/2] ipv6: fix possible infinite loop in rt6_fill_node()

[Ido Schimmel]

On Wed, May 27, 2026 at 01:31:30PM +0800, Jiayuan Chen wrote:
> Sashiko reported this issue [1]. Apply the same fix as
> commit f8d8ce1b515a ("ipv6: fix possible infinite loop in fib6_info_uses_dev()").
> 
> Writers holding tb6_lock can list_del_rcu(&rt->fib6_siblings)
> without waiting for RCU readers; rt->fib6_siblings.next then still
> points into the old ring and this softirq-side walker never reaches
> &rt->fib6_siblings, causing a CPU stall. fib6_purge_rt() always

s/fib6_purge_rt/fib6_del_route/ ?

> WRITE_ONCE()s rt->fib6_nsiblings to 0 before list_del_rcu(), so an
> inside-loop check is a reliable detach signal.
> 
> [1] https://sashiko.dev/#/patchset/20260526020227.4857-1-jiayuan.chen%40linux.dev
> 
> Fixes: d9ccb18f83ea ("ipv6: Fix soft lockups in fib6_select_path under high next hop churn")
> Signed-off-by: Jiayuan Chen <jiayuan.chen@linux.dev>

Reviewed-by: Ido Schimmel <idosch@nvidia.com>

Sashiko points out two pre-existing issues:

1. Same issue in nft_fib6_info_nh_uses_dev(). Fixed by:
https://lore.kernel.org/all/20260526020227.4857-1-jiayuan.chen@linux.dev/

2. Missing nlmsg_{end, cancel}() following ip6mr_get_route(). Seems
valid, but completely unrelated.

Re: [PATCH net 1/2] ipv6: fix possible infinite loop in rt6_fill_node()

[Jiayuan Chen]

On 5/28/26 4:45 PM, Ido Schimmel wrote:
> On Wed, May 27, 2026 at 01:31:30PM +0800, Jiayuan Chen wrote:
>> Sashiko reported this issue [1]. Apply the same fix as
>> commit f8d8ce1b515a ("ipv6: fix possible infinite loop in fib6_info_uses_dev()").
>>
>> Writers holding tb6_lock can list_del_rcu(&rt->fib6_siblings)
>> without waiting for RCU readers; rt->fib6_siblings.next then still
>> points into the old ring and this softirq-side walker never reaches
>> &rt->fib6_siblings, causing a CPU stall. fib6_purge_rt() always
> s/fib6_purge_rt/fib6_del_route/ ?

You're right, that's fib6_del_route().


>> WRITE_ONCE()s rt->fib6_nsiblings to 0 before list_del_rcu(), so an
>> inside-loop check is a reliable detach signal.
>>
>> [1] https://sashiko.dev/#/patchset/20260526020227.4857-1-jiayuan.chen%40linux.dev
>>
>> Fixes: d9ccb18f83ea ("ipv6: Fix soft lockups in fib6_select_path under high next hop churn")
>> Signed-off-by: Jiayuan Chen <jiayuan.chen@linux.dev>
> Reviewed-by: Ido Schimmel <idosch@nvidia.com>
>
> Sashiko points out two pre-existing issues:
>
> 1. Same issue in nft_fib6_info_nh_uses_dev(). Fixed by:
> https://lore.kernel.org/all/20260526020227.4857-1-jiayuan.chen@linux.dev/
>
> 2. Missing nlmsg_{end, cancel}() following ip6mr_get_route(). Seems
> valid, but completely unrelated.