From: Jarkko Sakkinen <jarkko@kernel.org>
To: David Howells <dhowells@redhat.com>
Cc: Kees Cook <kees@kernel.org>, Oleg Nesterov <oleg@redhat.com>,
Greg KH <gregkh@linuxfoundation.org>,
Josh Drake <josh@delphoslabs.com>,
Suraj Sonawane <surajsonawane0215@gmail.com>,
keyrings@vger.kernel.org, linux-security-module@vger.kernel.org,
security@kernel.org, stable@vger.kernel.org,
linux-kernel@vger.kernel.org
Subject: Re: [PATCH v2] keys: Fix UAF in key_put()
Date: Thu, 20 Mar 2025 20:48:13 +0200 [thread overview]
Message-ID: <Z9xi7ZD27-TKJp7u@kernel.org> (raw)
In-Reply-To: <Z9xijTBHY93HCsLW@kernel.org>
On Thu, Mar 20, 2025 at 08:46:41PM +0200, Jarkko Sakkinen wrote:
> On Thu, Mar 20, 2025 at 07:28:36PM +0200, Jarkko Sakkinen wrote:
> > On Thu, Mar 20, 2025 at 04:39:11PM +0000, David Howells wrote:
> > > Jarkko Sakkinen <jarkko@kernel.org> wrote:
> > >
> > > > > + if (test_bit(KEY_FLAG_FINAL_PUT, &key->flags)) {
> > > > > + smp_mb(); /* Clobber key->user after FINAL_PUT seen. */
> > > >
> > > > test_bit() is already atomic.
> > >
> > > Atomiticity doesn't apply to test_bit() - it only matters when it does two (or
> > > more) accesses that must be perceptually indivisible (e.g. set_bit doing RMW).
> > >
> > > But atomiticity isn't the issue here, hence the barrier. You need to be
> > > looking at memory-barriers.txt, not atomic_bitops.txt.
> > >
> > > We have two things to correctly order and set_bit() does not imply sufficient
> > > barriering; test_and_set_bit() does, but not set_bit(), hence Linus's comment
> > > about really wanting a set_bit_release().
> >
> > Oops, I was hallucinating here. And yeah, test_and_set_bit() does
> > imply full mb as you said.
> >
> > I was somehow remembering what I did in SGX driver incorrectly and
> > that led me into misconclusions, sorry.
> >
> > if (test_and_set_bit(SGX_ENCL_IOCTL, &encl->flags))
> > return -EBUSY;
> >
> > >
> > > > > + smp_mb(); /* key->user before FINAL_PUT set. */
> > > > > + set_bit(KEY_FLAG_FINAL_PUT, &key->flags);
> > > >
> > > > Ditto.
> > >
> > > Ditto. ;-)
> >
> > Duh, no need poke with the stick further (or deeper) ;-)
> >
> > >
> > > > Nit: I'm just thinking should the name imply more like that "now
> > > > key_put() is actually done". E.g., even something like KEY_FLAG_PUT_DONE
> > > > would be more self-descriptive.
> > >
> > > KEY_FLAG_PUT_DONE isn't right. There can be lots of puts on a single key -
> > > only the one that reduces it to 0 matters for this. You could call it
> > > KEY_FLAG_CAN_NOW_GC or KEY_FLAG_GC_ABLE.
> >
> > Well all alternatives are fine but my thinking was that one that finally
> > zeros the refcount, "finalizes put" (pick whatever you want anyway).
>
> I'll pick this one up tomorrow and put a PR out within this week.
I can try get this done tomorrow fully (with only one patch in the PR)
so that we would get it still to the ongoing release...
BR, Jarkko
prev parent reply other threads:[~2025-03-20 18:48 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-03-19 15:57 [PATCH v2] keys: Fix UAF in key_put() David Howells
2025-03-19 16:30 ` Oleg Nesterov
2025-03-19 18:11 ` Linus Torvalds
2025-03-19 18:47 ` David Howells
2025-03-20 16:14 ` Jarkko Sakkinen
2025-03-20 16:39 ` David Howells
2025-03-20 17:28 ` Jarkko Sakkinen
2025-03-20 18:46 ` Jarkko Sakkinen
2025-03-20 18:48 ` Jarkko Sakkinen [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=Z9xi7ZD27-TKJp7u@kernel.org \
--to=jarkko@kernel.org \
--cc=dhowells@redhat.com \
--cc=gregkh@linuxfoundation.org \
--cc=josh@delphoslabs.com \
--cc=kees@kernel.org \
--cc=keyrings@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-security-module@vger.kernel.org \
--cc=oleg@redhat.com \
--cc=security@kernel.org \
--cc=stable@vger.kernel.org \
--cc=surajsonawane0215@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).