Re: [PATCH] SUNRPC: Check if we need to recalculate slack estimates

[Salvatore Bonaccorso <carnil@debian.org>]

Hi Chuck, Scott,

On Wed, Nov 19, 2025 at 10:48:47AM -0500, Chuck Lever wrote:
> On 11/19/25 8:32 AM, Scott Mayhew wrote:
> > If the incoming GSS verifier is larger than what we previously recorded
> > on the gss_auth, that would indicate the GSS cred/context used for that
> > RPC is using a different enctype than the one used by the machine
> > cred/context, and we should recalculate the slack variables accordingly.
> > 
> > Link: https://bugs.debian.org/1120598
> > Signed-off-by: Scott Mayhew <smayhew@redhat.com>
> > ---
> >  net/sunrpc/auth_gss/auth_gss.c | 8 ++++++++
> >  1 file changed, 8 insertions(+)
> > 
> > diff --git a/net/sunrpc/auth_gss/auth_gss.c b/net/sunrpc/auth_gss/auth_gss.c
> > index 5c095cb8cb20..6da9ca08370d 100644
> > --- a/net/sunrpc/auth_gss/auth_gss.c
> > +++ b/net/sunrpc/auth_gss/auth_gss.c
> > @@ -1721,6 +1721,14 @@ gss_validate(struct rpc_task *task, struct xdr_stream *xdr)
> >  	if (maj_stat)
> >  		goto bad_mic;
> >  
> > +	/*
> > +	 * Normally we only recalculate the slack variables once after
> > +	 * creating a new gss_auth, but we should also do it if the incoming
> > +	 * verifier has a larger size than what was previously recorded.
> 
> No quibble with the code change, but IMO the comment should work a
> little harder to explain why the increase is needed. Something like:
> 
> 	* When the incoming verifier is larger than expected, the
> 	* GSS context is using a different enctype than the one used
> 	* initially by the machine credential. Force a slack size update
> 	* to maintain good payload alignment.
> 
> I'm summarizing based on your commit message above...
> 
> 
> > +	 */
> > +	if (cred->cr_auth->au_verfsize < (XDR_QUADLEN(len) + 2))
> > +		__set_bit(RPCAUTH_AUTH_UPDATE_SLACK, &cred->cr_auth->au_flags);
> > +
> >  	/* We leave it to unwrap to calculate au_rslack. For now we just
> >  	 * calculate the length of the verifier: */
> >  	if (test_bit(RPCAUTH_AUTH_UPDATE_SLACK, &cred->cr_auth->au_flags))

I was looking in Debian for the state of this and noticed this was
later on never applied/submitted to mainline, is this correct? Did it
felt through the cracks or is it considered not to be a problem to
further tackle?

Thanks a lot for your work and your help!

Regards,
Salvatore