From: Chuck Lever <cel@kernel.org>
To: Jeff Layton <jlayton@kernel.org>, NeilBrown <neil@brown.name>,
Olga Kornievskaia <okorniev@redhat.com>,
Dai Ngo <Dai.Ngo@oracle.com>, Tom Talpey <tom@talpey.com>,
Scott Mayhew <smayhew@redhat.com>,
Trond Myklebust <trondmy@kernel.org>,
Anna Schumaker <anna@kernel.org>
Cc: linux-nfs@vger.kernel.org, Chuck Lever <cel@kernel.org>
Subject: [PATCH v2 4/8] NFSD: Reject an oversized principal hash from nfsdcld
Date: Tue, 01 Sep 2026 16:19:44 -0400 [thread overview]
Message-ID: <20260901-alemi-v2-4-e163f94a3a6e@kernel.org> (raw)
In-Reply-To: <20260901-alemi-v2-0-e163f94a3a6e@kernel.org>
__cld_pipe_inprogress_downcall() takes the principal hash length
from the daemon's GraceStart downcall without checking it against
the cc_princhash payload it describes, which holds at most
SHA256_DIGEST_SIZE bytes. The length is stored verbatim in the
reclaim record, and nfsd4_cld_check_v2() later hands it to memcmp()
against a digest array of SHA256_DIGEST_SIZE bytes on the stack. A
length up to U8_MAX reads past the end of that array, and the stray
bytes can only make the comparison fail, denying the client its
reclaim. The pipe is mode 0600 in rpc_pipefs, so the trigger is a
broken or hostile nfsdcld rather than an unprivileged task.
Reject a length larger than the wire field, as the existing check
on the client name length does.
Fixes: 6ee95d1c8991 ("nfsd: add support for upcall version 2")
Signed-off-by: Chuck Lever <cel@kernel.org>
---
fs/nfsd/nfs4recover.c | 5 +++++
1 file changed, 5 insertions(+)
diff --git a/fs/nfsd/nfs4recover.c b/fs/nfsd/nfs4recover.c
index 999694db9981..8af935ed0c4e 100644
--- a/fs/nfsd/nfs4recover.c
+++ b/fs/nfsd/nfs4recover.c
@@ -730,6 +730,11 @@ __cld_pipe_inprogress_downcall(const struct cld_msg_v2 __user *cmsg,
name.len = namelen;
if (get_user(princhashlen, &ci->cc_princhash.cp_len))
return -EFAULT;
+ if (princhashlen > SHA256_DIGEST_SIZE) {
+ dprintk("%s: invalid princhashlen (%u)",
+ __func__, princhashlen);
+ return -EINVAL;
+ }
if (princhashlen > 0) {
princhashcopy = memdup_user(
&ci->cc_princhash.cp_data,
--
2.54.0
next prev parent reply other threads:[~2026-09-01 20:20 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-09-01 20:19 [PATCH v2 0/8] Fix premature completion of rpc_pipefs upcalls Chuck Lever
2026-09-01 20:19 ` [PATCH v2 1/8] NFSD: Don't complete a cld upcall the daemon has not read Chuck Lever
2026-09-01 20:19 ` [PATCH v2 2/8] NFSD: Move the cld upcall message out of the caller's stack frame Chuck Lever
2026-09-01 20:19 ` [PATCH v2 3/8] NFSD: Complete a cld upcall when copying its reply fails Chuck Lever
2026-09-01 20:19 ` Chuck Lever [this message]
2026-09-01 20:19 ` [PATCH v2 5/8] pnfs/blocklayout: Complete a device upcall only on its own reply Chuck Lever
2026-09-01 20:19 ` [PATCH v2 6/8] NFSD: Set nn->cld_net before registering the cld pipe Chuck Lever
2026-09-01 20:19 ` [PATCH v2 7/8] NFSD: Complete a cld upcall when the daemon closes the pipe Chuck Lever
2026-09-01 20:19 ` [PATCH v2 8/8] pnfs/blocklayout: Complete a device upcall when the pipe is closed Chuck Lever
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20260901-alemi-v2-4-e163f94a3a6e@kernel.org \
--to=cel@kernel.org \
--cc=Dai.Ngo@oracle.com \
--cc=anna@kernel.org \
--cc=jlayton@kernel.org \
--cc=linux-nfs@vger.kernel.org \
--cc=neil@brown.name \
--cc=okorniev@redhat.com \
--cc=smayhew@redhat.com \
--cc=tom@talpey.com \
--cc=trondmy@kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.