linux-kernel - Re: [PATCH v5 4/7] nfsd: when CB_SEQUENCE gets ESERVERFAULT don't increment seq

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <d7ed5f65-16f6-498d-82f0-6a008679ea0a@oracle.com>
Date: Sat, 8 Feb 2025 12:13:14 -0500
From: Chuck Lever <chuck.lever@...cle.com>
To: Jeff Layton <jlayton@...nel.org>, Neil Brown <neilb@...e.de>,
        Olga Kornievskaia <okorniev@...hat.com>, Dai Ngo <Dai.Ngo@...cle.com>,
        Tom Talpey <tom@...pey.com>, "J. Bruce Fields" <bfields@...ldses.org>
Cc: linux-nfs@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH v5 4/7] nfsd: when CB_SEQUENCE gets ESERVERFAULT don't
 increment seq_nr

On 2/7/25 4:53 PM, Jeff Layton wrote:
> ESERVERFAULT means that the server sent a successful and legitimate
> reply, but the session info didn't match what was expected. Don't
> increment the seq_nr in that case.
> 
> Signed-off-by: Jeff Layton <jlayton@...nel.org>
> ---
>  fs/nfsd/nfs4callback.c | 6 +++++-
>  1 file changed, 5 insertions(+), 1 deletion(-)
> 
> diff --git a/fs/nfsd/nfs4callback.c b/fs/nfsd/nfs4callback.c
> index 1e601075fac02bd5f01ff89d9252ab23d08c4fd9..d307ca1771bd1eca8f60b62a74170e71e5acf144 100644
> --- a/fs/nfsd/nfs4callback.c
> +++ b/fs/nfsd/nfs4callback.c
> @@ -1369,7 +1369,11 @@ static bool nfsd4_cb_sequence_done(struct rpc_task *task, struct nfsd4_callback
>  		ret = true;
>  		break;
>  	case -ESERVERFAULT:
> -		++session->se_cb_seq_nr[cb->cb_held_slot];
> +		/*
> +		 * Call succeeded, but CB_SEQUENCE reply failed sanity checks.
> +		 * The client has gone insane. Mark the BC faulty, since there
> +		 * isn't much else we can do.
> +		 */

I'm chewing on the "gone insane" remark. Since I'm tagging a few nits in
other spots: perhaps this comment could explain in more specific detail
why the server cannot trust this CB_SEQUENCE response. Maybe:

 /*
  * Call succeeded, but the session, slot index, or slot
  * sequence number in the response do not match the same
  * in the server's call. The sequence information is thus
  * untrustworthy.
  */

That's wordy, but you get the idea. Even better if we can find some
relevant spec language.


>  		nfsd4_mark_cb_fault(cb->cb_clp);
>  		break;
>  	case 1:
> 


-- 
Chuck Lever