[PATCH v2] keys: Fix UAF in key_put()

Jarkko Sakkinen jarkko at kernel.org
Thu Mar 20 18:48:13 UTC 2025


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 at 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



More information about the Linux-security-module-archive mailing list