From: Jinpyo Lee <bint4b13@gmail.com>
To: linux-nfs@vger.kernel.org
Cc: Chuck Lever <cel@kernel.org>, 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>,
Greg KH <gregkh@linuxfoundation.org>,
bobtobabz@gmail.com, Jinpyo Lee <bint4b13@gmail.com>
Subject: [PATCH v2] nfsd: bounds-check opnum before testing spo_must_allow
Date: Wed, 30 Sep 2026 14:54:14 +0900 [thread overview]
Message-ID: <20260930055414.136306-1-bint4b13@gmail.com> (raw)
The NFSv4 decoder represents an unknown wire operation as OP_ILLEGAL,
whose value is outside struct nfs4_op_map. nfsd4_spo_must_allow() passes
that value directly to test_bit(), causing an out-of-bounds bitmap read
when an invalid operation follows a successfully processed operation.
For an SP4_MACH_CRED client, a set out-of-bounds bit also marks the
compound as spo_must_allowed. Validation used the nfsd-testing base
recorded below. On the unmodified KASAN kernel with an empty allow bitmap,
the out-of-bounds bit changed the export security-flavor result from
NFS4ERR_WRONGSEC to NFS4_OK for 64 of 72 client instances. A krb5i canary
read then succeeded through a sec=krb5p export. The current allocation
layout did not produce a KASAN report for this invalid bitmap access.
Reject operation numbers above LAST_NFS4_OP before testing the bitmap.
AUTH_NULL reaches the invalid load. The observed security-flavor decision
change additionally requires a valid SP4_MACH_CRED client and matching GSS
credentials; ordinary POSIX permissions remained enforced. Source
reproducers and complete logs are available privately on request. A legal
OP_CLOSE control also allowed the preceding read, so the read itself is
not claimed as a capability unique to this OOB.
With this patch, none of the 72 client instances caused the export
security-flavor check to return NFS4_OK for the invalid-operation probe,
and the canary read was denied. The legal OP_CLOSE and empty-bitmap
controls retained their expected behavior, and no KASAN report was
observed. The full KASAN kernel built with CONFIG_WERROR without a compiler
diagnostic. Basic NFSv4.2 and NFSv3 read/write/unmount smoke tests also
passed.
The vulnerability research and validation were conducted by members of
the Tobabz team as part of the Best of the Best 15th program.
Fixes: ed94164398c9 ("nfsd: implement machine credential support for some operations")
Assisted-by: LLM
Signed-off-by: Jinpyo Lee <bint4b13@gmail.com>
---
Changes in v2:
- Make the current policy impact and controls self-contained.
- Add full-build and NFSv4.2/NFSv3 smoke-test results.
- No code changes.
fs/nfsd/nfs4proc.c | 7 ++++---
1 file changed, 4 insertions(+), 3 deletions(-)
diff --git a/fs/nfsd/nfs4proc.c b/fs/nfsd/nfs4proc.c
index 7df60abfb..f9e119cd0 100644
--- a/fs/nfsd/nfs4proc.c
+++ b/fs/nfsd/nfs4proc.c
@@ -4293,9 +4293,10 @@ bool nfsd4_spo_must_allow(struct svc_rqst *rqstp)
opiter = resp->opcnt;
while (opiter < argp->opcnt) {
this = &argp->ops[opiter++];
- if (test_bit(this->opnum, allow->u.longs) &&
- cstate->clp->cl_mach_cred &&
- nfsd4_mach_creds_match(cstate->clp, rqstp)) {
+ if (this->opnum <= LAST_NFS4_OP &&
+ test_bit(this->opnum, allow->u.longs) &&
+ cstate->clp->cl_mach_cred &&
+ nfsd4_mach_creds_match(cstate->clp, rqstp)) {
cstate->spo_must_allowed = true;
return true;
}
base-commit: 32eb1a60b456980761cf7a9cee8f907fdc08afb8
--
2.50.1 (Apple Git-155)
next reply other threads:[~2026-09-30 5:54 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-09-30 5:54 Jinpyo Lee [this message]
2026-10-05 15:04 ` [PATCH v2] nfsd: bounds-check opnum before testing spo_must_allow 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=20260930055414.136306-1-bint4b13@gmail.com \
--to=bint4b13@gmail.com \
--cc=Dai.Ngo@oracle.com \
--cc=bobtobabz@gmail.com \
--cc=cel@kernel.org \
--cc=gregkh@linuxfoundation.org \
--cc=jlayton@kernel.org \
--cc=linux-nfs@vger.kernel.org \
--cc=neil@brown.name \
--cc=okorniev@redhat.com \
--cc=tom@talpey.com \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox