All of lore.kernel.org
 help / color / mirror / Atom feed
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

  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.