All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jeff Layton <jlayton@kernel.org>
To: Hyunsol Mun <muumthf@gmail.com>, linux-nfs@vger.kernel.org
Cc: Chuck Lever <cel@kernel.org>, NeilBrown <neil@brown.name>,
	Olga Kornievskaia <okorniev@redhat.com>,
	Dai Ngo <Dai.Ngo@oracle.com>, Tom Talpey <tom@talpey.com>,
	Willy Tarreau	 <w@1wt.eu>,
	bobtobabz@gmail.com
Subject: Re: [PATCH v2] nfsd: pin OPEN stateid referenced by LOCK stateid
Date: Fri, 02 Oct 2026 08:09:22 +0100	[thread overview]
Message-ID: <8cfb77a14656dc4b8efd4cd77dbb88898025d7c5.camel@kernel.org> (raw)
In-Reply-To: <20260930053646.299164-1-muumthf@gmail.com>

On Wed, 2026-09-30 at 14:36 +0900, Hyunsol Mun wrote:
> A LOCK stateid stores its parent OPEN stateid in st_openstp without taking
> a reference. A request can keep the child alive while a concurrent CLOSE
> unhashes the child and releases the parent's persistent reference. A READ
> using the surviving LOCK stateid then follows the freed parent in
> nfs4_check_openmode().
> 
> Take an OPEN stateid reference when initializing the LOCK stateid and
> release it from the LOCK stateid free callback. Keep the free path safe
> for partially initialized objects.
> 
> An unprivileged NFSv4.1 client with normal access to an exported file can
> reach the lifetime error using ordinary OPEN, LOCK, READ, and CLOSE
> operations. Validation used the nfsd-testing base recorded below. Natural
> race runs on the unmodified KASAN kernel completed 3,000 one-reader
> attempts and 5,000 eight-reader attempts without reproducing the report.
> 
> For deterministic validation, a test-only kprobe delayed
> nfs4_check_openmode() after LOCK setup, before it followed st_openstp. The
> module only widened the race window; it did not allocate, free, or modify
> an NFSD object. The unpatched kernel then reported a slab use-after-free in
> nfs4_check_openmode() on the first timed attempt. With this patch, the same
> timed READ and CLOSE both returned NFS4_OK and produced no KASAN report.
> 
> The patched kernel also completed the natural 3,000-attempt run and the
> 5,000-attempt eight-reader run without a KASAN report or kernel failure.
> The full KASAN kernel built with CONFIG_WERROR without a compiler
> diagnostic. Basic NFSv4.2 and NFSv3 read/write/unmount smoke tests passed.
> A source reproducer, timing-module source, complete logs, and the kernel
> configuration are available privately on request.
> 
> The vulnerability research and validation were conducted by members of
> the Tobabz team as part of the Best of the Best 15th program.
> 
> Fixes: 02921914170e ("nfsd4: fix openmode checking on IO using lock stateid")
> Assisted-by: LLM
> Signed-off-by: Hyunsol Mun <muumthf@gmail.com>
> ---
> Changes in v2:
> - Separate natural-race and timing-assisted validation results.
> - Add full-build and NFSv4.2/NFSv3 smoke-test results.
> - No code changes.
> 
>  fs/nfsd/nfs4state.c | 4 ++++
>  1 file changed, 4 insertions(+)
> 
> diff --git a/fs/nfsd/nfs4state.c b/fs/nfsd/nfs4state.c
> index bbc16dd22..208badfe6 100644
> --- a/fs/nfsd/nfs4state.c
> +++ b/fs/nfsd/nfs4state.c
> @@ -1781,6 +1781,7 @@ static void nfs4_free_ol_stateid(struct nfs4_stid *stid)
>  static void nfs4_free_lock_stateid(struct nfs4_stid *stid)
>  {
>  	struct nfs4_ol_stateid *stp = openlockstateid(stid);
> +	struct nfs4_ol_stateid *open_stp = stp->st_openstp;
>  	struct nfs4_lockowner *lo = lockowner(stp->st_stateowner);
>  	struct nfsd_file *nf;
>  
> @@ -1791,6 +1792,8 @@ static void nfs4_free_lock_stateid(struct nfs4_stid *stid)
>  		nfsd_file_put(nf);
>  	}
>  	nfs4_free_ol_stateid(stid);
> +	if (open_stp)
> +		nfs4_put_stid(&open_stp->st_stid);
>  }
>  
>  /*
> @@ -9301,6 +9304,7 @@ init_lock_stateid(struct nfs4_ol_stateid *stp, struct nfs4_lockowner *lo,
>  			exp_get(open_stp->st_stid.sc_export);
>  	stp->st_access_bmap = 0;
>  	stp->st_deny_bmap = open_stp->st_deny_bmap;
> +	refcount_inc(&open_stp->st_stid.sc_count);
>  	stp->st_openstp = open_stp;
>  	spin_lock(&fp->fi_lock);
>  	list_add(&stp->st_locks, &open_stp->st_locks);
> 
> base-commit: 32eb1a60b456980761cf7a9cee8f907fdc08afb8

LGTM

Reviewed-by: Jeff Layton <jlayton@kernel.org>

  reply	other threads:[~2026-10-02  7:09 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-09-30  5:36 [PATCH v2] nfsd: pin OPEN stateid referenced by LOCK stateid Hyunsol Mun
2026-10-02  7:09 ` Jeff Layton [this message]
2026-10-05 15:03 ` 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=8cfb77a14656dc4b8efd4cd77dbb88898025d7c5.camel@kernel.org \
    --to=jlayton@kernel.org \
    --cc=Dai.Ngo@oracle.com \
    --cc=bobtobabz@gmail.com \
    --cc=cel@kernel.org \
    --cc=linux-nfs@vger.kernel.org \
    --cc=muumthf@gmail.com \
    --cc=neil@brown.name \
    --cc=okorniev@redhat.com \
    --cc=tom@talpey.com \
    --cc=w@1wt.eu \
    /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.