All of lore.kernel.org
 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 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.