Re: [PATCH] keys: big_key: Reserve the final quota before destroying the payload

[Jarkko Sakkinen]

On Sat, Oct 17, 2026 at 02:33:10AM +0300, Jarkko Sakkinen wrote:
> On Fri, Oct 16, 2026 at 01:00:04PM +0900, Daehyeon Ko wrote:
> > A big_key is charged a fixed 16 bytes of key quota, regardless of the
> > actual payload size.  big_key_update() currently reserves the actual new
> > payload length before destroying the old payload, while the subsequent
> > generic_key_instantiate() reserves the fixed quota length.
> > 
> > For an update to a payload shorter than 16 bytes, the first reservation
> > temporarily returns quota.  Another key operation by the same user can
> > consume that quota before generic_key_instantiate() tries to reserve it
> > again.  If that second reservation fails, the key remains instantiated but
> > its old big_key payload has already been destroyed.  Reading a
> > buffer-backed key or revoking a shmem-backed key then dereferences a NULL
> > payload pointer.
> 
> Even at the risk that I'm saying something stupid, makes me
> wonder why the call exists in big_key.c? I.e. why not remove
> the call instead of doing what the patch does?
> 
> If I'm now missing something out, that's cool, just correct
> me.

So the way I see it this patch has the right bug and a wrong fix.

I.e. if you still want to move forward with this fix, explain
why two repeated calls are still a necessity. Then we can ensure
that the fix addressing the root cause.

Alternatively rewrite the patch so that it makes the call path have
only a single call site for key_payload_reserve().

Br. Jarkko