From: Ido Schimmel <idosch@nvidia.com>
To: "Nikola Z. Ivanov" <zlatistiv@gmail.com>
Cc: dsahern@kernel.org, davem@davemloft.net, edumazet@google.com,
kuba@kernel.org, pabeni@redhat.com, horms@kernel.org,
kuniyu@google.com, netdev@vger.kernel.org,
linux-kernel@vger.kernel.org,
syzbot+84d4a405ed798b40c96d@syzkaller.appspotmail.com
Subject: Re: [PATCH net] ipv6: Change allocation flags to match rcu_read_lock section requirements
Date: Sun, 19 Jul 2026 15:55:07 +0300 [thread overview]
Message-ID: <20260719125507.GA2005035@shredder> (raw)
In-Reply-To: <20260719105759.558050-1-zlatistiv@gmail.com>
On Sun, Jul 19, 2026 at 01:57:59PM +0300, Nikola Z. Ivanov wrote:
> Since the call to __ip6_del_rt_siblings has been converted under
> rcu read lock and it only has one call point
> we should no longer block or yield.
>
> Our stack trace from the syzbot reproducer looks as follows:
>
> __ip6_del_rt_siblings
> rtnl_notify (Here we pass gfp_any() -> GFP_KERNEL)
> nlmsg_notify
> nlmsg_multicast
> nlmsg_multicast_filtered
> netlink_broadcast_filtered (GFP_KERNEL passed from earlier)
>
> netlink_broadcast_filtered can yield if GFP_KERNEL
> is passed, which we do not want to happen.
>
> Fix this by changing the allocation flag of rtnl_notify.
>
> Also change the flag passed to nlmsg_new. Even though it
> is not related to the syzbot generated bug it still falls
> under the same requirements.
I believe that the nlmsg_new() change is a no-op given that gfp_any()
evaluates to GFP_ATOMIC under spin_lock_bh(), but it makes
__ip6_del_rt_siblings() consistent with inet6_rt_notify() which already
uses GFP_ATOMIC for both nlmsg_new() and rtnl_notify().
>
> Reported-by: syzbot+84d4a405ed798b40c96d@syzkaller.appspotmail.com
> Closes: https://syzkaller.appspot.com/bug?extid=84d4a405ed798b40c96d
> Fixes: bd11ff421d36 ("ipv6: Get rid of RTNL for SIOCDELRT and RTM_DELROUTE.")
> Signed-off-by: Nikola Z. Ivanov <zlatistiv@gmail.com>
Reviewed-by: Ido Schimmel <idosch@nvidia.com>
prev parent reply other threads:[~2026-07-19 12:55 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-07-19 10:57 [PATCH net] ipv6: Change allocation flags to match rcu_read_lock section requirements Nikola Z. Ivanov
2026-07-19 12:55 ` Ido Schimmel [this message]
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=20260719125507.GA2005035@shredder \
--to=idosch@nvidia.com \
--cc=davem@davemloft.net \
--cc=dsahern@kernel.org \
--cc=edumazet@google.com \
--cc=horms@kernel.org \
--cc=kuba@kernel.org \
--cc=kuniyu@google.com \
--cc=linux-kernel@vger.kernel.org \
--cc=netdev@vger.kernel.org \
--cc=pabeni@redhat.com \
--cc=syzbot+84d4a405ed798b40c96d@syzkaller.appspotmail.com \
--cc=zlatistiv@gmail.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.