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

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

[Scott Mayhew]

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.
+	 */
+	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))
-- 
2.51.0

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

[Chuck Lever]

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


-- 
Chuck Lever

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

[Salvatore Bonaccorso]

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

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

[Chuck Lever]

On 1/2/26 7:34 AM, Salvatore Bonaccorso wrote:
> 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?

Hello Salvatore -

After further consideration, we concluded the above change is not an
adequate repair for this issue. The winter holidays have prevented
further progress, but I expect Scott will continue looking into a better
fix starting next week.


-- 
Chuck Lever

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

[Scott Mayhew]

On Fri, 02 Jan 2026, Salvatore Bonaccorso wrote:

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

Sorry for the delay.  After having had a chance to take a deeper look,
I think it would be better to try to address this from the rpc.gssd side
instead of trying to make the kernel cope with having to bounce around
between different encryption types.

Unfortunately I fat-fingered your email address when I sent the patches,
so here's the link:
https://lore.kernel.org/linux-nfs/20260213224012.2608126-1-smayhew@redhat.com/T/#t

-Scott
> 
> Regards,
> Salvatore
> 

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

[Salvatore Bonaccorso]

Hi Scott,

On Fri, Feb 13, 2026 at 05:45:15PM -0500, Scott Mayhew wrote:
> On Fri, 02 Jan 2026, Salvatore Bonaccorso wrote:
> 
> > 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!
> 
> Sorry for the delay.  After having had a chance to take a deeper look,
> I think it would be better to try to address this from the rpc.gssd side
> instead of trying to make the kernel cope with having to bounce around
> between different encryption types.
> 
> Unfortunately I fat-fingered your email address when I sent the patches,
> so here's the link:
> https://lore.kernel.org/linux-nfs/20260213224012.2608126-1-smayhew@redhat.com/T/#t

Thank you for the notice, I will watch the thread there with the new
patches.

Many thanks for all your work!

Regards,
Salvatore