From: Paolo Abeni <pabeni@redhat.com>
To: Chengfeng Ye <nicoyip.dev@gmail.com>,
"David S. Miller" <davem@davemloft.net>,
Eric Dumazet <edumazet@google.com>,
Jakub Kicinski <kuba@kernel.org>, Simon Horman <horms@kernel.org>,
Willem de Bruijn <willemb@google.com>,
Nikolay Aleksandrov <razor@blackwall.org>,
Qi Zhang <marsy12010123@gmail.com>,
Randy Dunlap <rdunlap@infradead.org>,
Alice Mikityanska <alice.kernel@fastmail.im>,
Florian Westphal <fw@strlen.de>,
Jesper Dangaard Brouer <hawk@kernel.org>
Cc: netdev@vger.kernel.org, linux-kernel@vger.kernel.org,
stable@vger.kernel.org
Subject: Re: [PATCH net] net: pktgen: keep device lookup under RCU protection
Date: Tue, 25 Aug 2026 12:45:02 +0200 [thread overview]
Message-ID: <f3a9dd1f-43a7-4644-bf1a-45dcd422abcb@redhat.com> (raw)
In-Reply-To: <20260824152331.216494-1-nicoyip.dev@gmail.com>
On 8/24/26 5:23 PM, Chengfeng Ye wrote:
> pktgen_find_dev() releases its RCU read-side critical section before
> returning pkt_dev. __pktgen_NN_threads() then sets removal_mark through
> that unprotected pointer.
>
> The worker can concurrently remove the device and queue it for RCU
> freeing:
>
> CPU 0 (netdevice unregister) CPU 1 (kpktgend)
> rcu_read_lock()
> find pkt_dev
> rcu_read_unlock()
> list_del_rcu(&pkt_dev->list)
> kfree_rcu(pkt_dev, rcu)
> RCU grace period ends
> pkt_dev->removal_mark = 1
>
> The mutex held by CPU 0 does not cover the worker and does not delay an
> RCU grace period, so the final write can access freed memory. KASAN
> reported:
>
> BUG: KASAN: slab-use-after-free in __pktgen_NN_threads+0x241/0x280
> Write of size 4 at addr ffff88810dab804c
> Call Trace:
> __pktgen_NN_threads+0x241/0x280
> pktgen_device_event+0x24e/0x3d0
> unregister_netdevice_many_notify+0xde8/0x1ec0
> rtnl_dellink+0x35d/0xa90
> Allocated by task 92:
> __kasan_kmalloc+0x8f/0xa0
> pktgen_thread_write+0x498/0x14e0
> Freed by task 0:
> __kasan_slab_free+0x43/0x70
> rcu_core+0x50a/0x1850
>
> Move the existing RCU read lock into the sole caller and release it only
> after setting removal_mark. The object therefore remains alive through
> the dereference, while lookup order and control handling remain
> unchanged.
>
> Fixes: 8788370a1d4b ("pktgen: RCU-ify "if_list" to remove lock in next_to_run()")
> Cc: stable@vger.kernel.org
> Signed-off-by: Chengfeng Ye <nicoyip.dev@gmail.com>
> ---
> net/core/pktgen.c | 7 ++++---
> 1 file changed, 4 insertions(+), 3 deletions(-)
>
> diff --git a/net/core/pktgen.c b/net/core/pktgen.c
> index 7f81aed46672..4fb1853589b3 100644
> --- a/net/core/pktgen.c
> +++ b/net/core/pktgen.c
> @@ -2032,14 +2032,17 @@ static struct pktgen_dev *__pktgen_NN_threads(const struct pktgen_net *pn,
> bool exact = (remove == FIND);
>
> list_for_each_entry(t, &pn->pktgen_threads, th_list) {
> + rcu_read_lock();
> pkt_dev = pktgen_find_dev(t, ifname, exact);
> if (pkt_dev) {
> if (remove) {
> pkt_dev->removal_mark = 1;
> t->control |= T_REMDEV;
> }
> - break;
> }
> + rcu_read_unlock();
> + if (pkt_dev)
> + break;
> }
> return pkt_dev;
Side note: returning the RCU protected ptr outside the RCU read lock
safe, as the caller never deference it, but quite confusing.
It would be nice to follow-up on net-next replacing the return type here
with a bool.
/P
next prev parent reply other threads:[~2026-08-25 10:45 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-08-24 15:23 [PATCH net] net: pktgen: keep device lookup under RCU protection Chengfeng Ye
2026-08-24 15:38 ` Eric Dumazet
2026-08-25 10:45 ` Paolo Abeni [this message]
2026-08-25 18:55 ` Chengfeng Ye
2026-08-25 18:53 ` [PATCH net-next] net: pktgen: return bool from __pktgen_NN_threads() Chengfeng Ye
2026-08-27 8:16 ` Paolo Abeni
2026-09-27 14:07 ` Chengfeng Ye
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=f3a9dd1f-43a7-4644-bf1a-45dcd422abcb@redhat.com \
--to=pabeni@redhat.com \
--cc=alice.kernel@fastmail.im \
--cc=davem@davemloft.net \
--cc=edumazet@google.com \
--cc=fw@strlen.de \
--cc=hawk@kernel.org \
--cc=horms@kernel.org \
--cc=kuba@kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=marsy12010123@gmail.com \
--cc=netdev@vger.kernel.org \
--cc=nicoyip.dev@gmail.com \
--cc=razor@blackwall.org \
--cc=rdunlap@infradead.org \
--cc=stable@vger.kernel.org \
--cc=willemb@google.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.