From: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
To: "Paul E. McKenney" <paulmck@kernel.org>
Cc: Petr Pavlu <petr.pavlu@suse.com>,
Luis Chamberlain <mcgrof@kernel.org>,
Daniel Gomez <da.gomez@kernel.org>,
Sami Tolvanen <samitolvanen@google.com>,
Aaron Tomlin <atomlin@atomlin.com>,
linux-modules@vger.kernel.org
Subject: Re: [PATCH net v2] ppp: defer channel free to an RCU grace period to fix pppol2tp RX UAF
Date: Tue, 14 Jul 2026 18:01:04 +0200 [thread overview]
Message-ID: <20260714160104.jK83e41c@linutronix.de> (raw)
In-Reply-To: <70060a4e-4630-487f-8ecc-4408e23268d4@paulmck-laptop>
On 2026-07-08 12:22:58 [-0700], Paul E. McKenney wrote:
> The RCU-callback ordering guarantees are quite weak:
…
So this is not working.
> What you maybe *could* do is to have the two RCU callbacks communicate,
> so that the last one to be invoked did the work of both of them. For
> example, use a shared variable initialized to 2, then have each callback
> do atomic_dec_and_test(), with the "winner" doing the work.
>
> Would that do the trick?
This would work but we would have to fix each one or make it slower for
everyone in the common case. So I think adding a rcu_barrier() to module
unload wouldn't be that bad and Petr did not say "get out" so ;)
I've been looking a bit more:
- fs/netfs/objects.c
call_rcu(&rreq->rcu, netfs_free_request_rcu). No rcu_barrier or
flush_worker.
- net/sched/sch_taprio.c
call_rcu(&oper->rcu, taprio_free_sched_cb) from with the destroy
callback. There is a rcu_barrier() but for classification not qdisc.
- drivers/net/tun.c.
tun_free_netdev() from the net_device::priv_destructor.
The net things _might_ be okay since there is netdev_run_todo() with a
rcu_barrier() which is run at rtnl_unlock(). So it might work.
- drivers/vfio/pci/vfio_pci_core.c
call_rcu() but I don't see anything rcu_barrier() like.
- security/keys/trusted-keys/trusted_core.c
security/keys/encrypted-keys/encrypted.c
call_rcu() from an update callback. No rcu_barrier in security/.
This looks "easy".
- drivers/gpu/drm/lima/lima_sched.c
lima_fence_release() does call_rcu() from an release callback. Don't
see anything that would enforce a rcu barrier here. The remove path
has also a lima_sched_slab_fini() which removes the slab cache used in
the rcu callback.
And we had the infinibad thing which got fixed in the meantime.
So I *think* this qualifies for an rcu_barrier() in the module unload
path. No objections I guess?
> Thanx, Paul
Sebastian
next prev parent reply other threads:[~2026-07-14 16:01 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-07-01 18:12 [PATCH net v2] ppp: defer channel free to an RCU grace period to fix pppol2tp RX UAF Norbert Szetei
2026-07-02 8:19 ` Qingfang Deng
2026-07-03 16:05 ` Guillaume Nault
2026-07-03 7:27 ` Qingfang Deng
2026-07-03 16:32 ` Breno Leitao
2026-07-05 2:57 ` Qingfang Deng
2026-07-06 9:29 ` Sebastian Andrzej Siewior
2026-07-07 15:32 ` Petr Pavlu
2026-07-07 16:39 ` Paul E. McKenney
2026-07-08 9:11 ` Sebastian Andrzej Siewior
2026-07-08 14:01 ` Paul E. McKenney
2026-07-08 7:49 ` Sebastian Andrzej Siewior
2026-07-08 13:04 ` Petr Pavlu
2026-07-08 13:56 ` Sebastian Andrzej Siewior
2026-07-08 19:00 ` Sebastian Andrzej Siewior
2026-07-08 19:22 ` Paul E. McKenney
2026-07-14 16:01 ` Sebastian Andrzej Siewior [this message]
2026-07-14 17:47 ` Paul E. McKenney
2026-07-06 7:22 ` Norbert Szetei
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=20260714160104.jK83e41c@linutronix.de \
--to=bigeasy@linutronix.de \
--cc=atomlin@atomlin.com \
--cc=da.gomez@kernel.org \
--cc=linux-modules@vger.kernel.org \
--cc=mcgrof@kernel.org \
--cc=paulmck@kernel.org \
--cc=petr.pavlu@suse.com \
--cc=samitolvanen@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.