Linux NFS development
 help / color / mirror / Atom feed
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)

             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