[PATCH v3 2/3] KEYS: Reject @desclen values >= KEY_MAX_DESC_SIZE in key_alloc()

[Jarkko Sakkinen]

On Tue, Oct 20, 2026 at 03:50:13PM +0000, Eric Biggers wrote:
> On Tue, Oct 20, 2026 at 04:00:31PM +0300, Jarkko Sakkinen wrote:
> > On Tue, Oct 20, 2026 at 01:57:19PM +0300, Jarkko Sakkinen wrote:
> > > > Sure, this fix is still incomplete though, as I mentioned.
> > > > 
> > > > Turns out Sashiko found this too; see the comment on
> > > > https://sashiko.dev/#/patchset/20261020013903.1244157-1-jarkko%40kernel.org
> > > 
> > > I did not ignore what you said honestly but I overlooked generated
> > > descriptions.
> > > 
> > > By comparing your v2 response and Sashiko's response and going through the
> > > code this is the list that I have where similar check should be placed:
> > > 
> > > - key_alloc(): before quota calculation (in place)
> > > - __key_create_or_update():  before assigning index_key.desc_len
> > > - keyring_search(): before match_preparse
> > > - request_key_and_link(): before match_preparse 
> > > - request_key_rcu(): before check_cached_key()
> > > 
> > > Some sites might require some minor changes I just wrote the around the
> > > ballpark locations.
> > > 
> > > Did I miss any site that you are aware of?
> 
> It looks okay to me.
> 
> > - Would it make sense to wrap strlen + check into key_is_valid_desc()?
> 
> I don't think it would be very helpful.

I tend to agree.

> 
> > - Would it make sense as a safe-guard to use strnlen(), which is capped
> >   to KEY_MAX_DESC_SIZE?
> 
> Not really needed.  They are NUL-terminated strings anyway.

This is what I thought based on that in all of the sites I could
determine where the string is create/sourced.

Just wanted to sanity check so that this does not require too
many additional iterations.

> 
> - Eric

Br, Jarkko