From: Ido Schimmel <idosch@nvidia.com>
To: netdev@vger.kernel.org
Cc: davem@davemloft.net, kuba@kernel.org, pabeni@redhat.com,
edumazet@kernel.org, dsahern@kernel.org, horms@kernel.org,
andrew+netdev@lunn.ch, petrm@nvidia.com,
Ido Schimmel <idosch@nvidia.com>
Subject: [PATCH net 1/2] ipv6: Hold RCU when emitting route hardware flags notification
Date: Mon, 19 Oct 2026 17:03:36 +0300 [thread overview]
Message-ID: <20261019140337.2886875-2-idosch@nvidia.com> (raw)
In-Reply-To: <20261019140337.2886875-1-idosch@nvidia.com>
fib6_info_hw_flags_set() is called by drivers from process context
without RTNL or RCU. When the route uses a nexthop object,
rt6_nlmsg_size() and rt6_fill_node() access the nexthop's RCU protected
nexthop info and group pointers via rcu_dereference_rtnl(), resulting in
suspicious RCU usage splats [1].
Fix by holding RCU while sizing and filling the notification, like
fib_alias_hw_flags_set() already does. Switch to GFP_ATOMIC for the skb
allocation accordingly.
Reproducer:
# echo "10 0" > /sys/bus/netdevsim/new_device
# sysctl -wq net.ipv6.fib_notify_on_flag_change=1
# sysctl -wq net.ipv4.nexthop_compat_mode=1
# ip -6 nexthop add id 1 blackhole
# ip -6 route add 2001:db8:1::1/128 nhid 1
[1]
WARNING: suspicious RCU usage
7.3.0-rc7-virtme-g191aa41548b2 #38 Not tainted
net/ipv4/nexthop.c:1539 suspicious rcu_dereference_check() usage!
[...]
Workqueue: events nsim_fib_event_work
Call Trace:
<TASK>
dump_stack_lvl (lib/dump_stack.c:94 lib/dump_stack.c:120)
lockdep_rcu_suspicious.cold (kernel/locking/lockdep.c:6972)
nexthop_for_each_fib6_nh (net/ipv4/nexthop.c:1539 (discriminator 16))
rt6_nlmsg_size (net/ipv6/route.c:5728)
fib6_info_hw_flags_set (net/ipv6/route.c:6503)
nsim_fib6_rt_add (drivers/net/netdevsim/fib.c:671 drivers/net/netdevsim/fib.c:694)
nsim_fib6_rt_insert (drivers/net/netdevsim/fib.c:759)
nsim_fib_event_work (drivers/net/netdevsim/fib.c:856 drivers/net/netdevsim/fib.c:889 drivers/net/netdevsim/fib.c:1493)
process_one_work (kernel/workqueue.c:3396)
worker_thread (kernel/workqueue.c:3479 kernel/workqueue.c:3560)
kthread (kernel/kthread.c:436)
ret_from_fork (arch/x86/kernel/process.c:158)
ret_from_fork_asm (arch/x86/entry/entry_64.S:245)
</TASK>
Fixes: 907eea486888 ("net: ipv6: Emit notification when fib hardware flags are changed")
Reported-by: Sashiko <netdev-bot+sashiko@kernel.org>
Closes: https://lore.kernel.org/netdev/179152182668.434549.18232968419539498055@kernel.org/
Assisted-by: LLM
Signed-off-by: Ido Schimmel <idosch@nvidia.com>
---
net/ipv6/route.c | 7 ++++++-
1 file changed, 6 insertions(+), 1 deletion(-)
diff --git a/net/ipv6/route.c b/net/ipv6/route.c
index a5e955e56e79..ab355e86ea54 100644
--- a/net/ipv6/route.c
+++ b/net/ipv6/route.c
@@ -6500,7 +6500,9 @@ void fib6_info_hw_flags_set(struct net *net, struct fib6_info *f6i,
if (!fib_notify_on_flag_change)
return;
- skb = nlmsg_new(rt6_nlmsg_size(f6i), GFP_KERNEL);
+ rcu_read_lock();
+
+ skb = nlmsg_new(rt6_nlmsg_size(f6i), GFP_ATOMIC);
if (!skb) {
err = -ENOBUFS;
goto errout;
@@ -6513,10 +6515,13 @@ void fib6_info_hw_flags_set(struct net *net, struct fib6_info *f6i,
goto errout;
}
+ rcu_read_unlock();
+
rtnl_notify(skb, net, 0, RTNLGRP_IPV6_ROUTE, NULL, GFP_KERNEL);
return;
errout:
+ rcu_read_unlock();
rtnl_set_sk_err(net, RTNLGRP_IPV6_ROUTE, err);
}
EXPORT_SYMBOL(fib6_info_hw_flags_set);
--
2.56.0
next prev parent reply other threads:[~2026-10-19 14:05 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-10-19 14:03 [PATCH net 0/2] ipv6: Fix suspicious RCU usage in route hardware flags notification Ido Schimmel
2026-10-19 14:03 ` Ido Schimmel [this message]
2026-10-19 17:23 ` [PATCH net 1/2] ipv6: Hold RCU when emitting " Eric Dumazet
2026-10-19 14:03 ` [PATCH net 2/2] selftests: netdevsim: Add FIB notification tests for nexthop objects Ido Schimmel
2026-10-19 17:39 ` Eric Dumazet
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=20261019140337.2886875-2-idosch@nvidia.com \
--to=idosch@nvidia.com \
--cc=andrew+netdev@lunn.ch \
--cc=davem@davemloft.net \
--cc=dsahern@kernel.org \
--cc=edumazet@kernel.org \
--cc=horms@kernel.org \
--cc=kuba@kernel.org \
--cc=netdev@vger.kernel.org \
--cc=pabeni@redhat.com \
--cc=petrm@nvidia.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.