From: Jeff Layton <jlayton@kernel.org>
To: Wentao Liang <vulab@iscas.ac.cn>, Chuck Lever <chuck.lever@oracle.com>
Cc: NeilBrown <neil@brown.name>,
Olga Kornievskaia <okorniev@redhat.com>,
Dai Ngo <Dai.Ngo@oracle.com>, Tom Talpey <tom@talpey.com>,
linux-nfs@vger.kernel.org, linux-kernel@vger.kernel.org,
stable@vger.kernel.org
Subject: Re: [PATCH] nfsd: fix use-after-free in nfsd4_lock() when releasing new lock stateid
Date: Mon, 18 May 2026 12:39:00 -0400 [thread overview]
Message-ID: <1013d4caa10d79eeab095ca51cdc4f243d6eb798.camel@kernel.org> (raw)
In-Reply-To: <20260518153048.1343021-1-vulab@iscas.ac.cn>
On Mon, 2026-05-18 at 15:30 +0000, Wentao Liang wrote:
> When processing a new lock request that fails with an error,
> nfsd4_lock() may call release_lock_stateid() on a newly created
> lock stateid. release_lock_stateid() can free the stateid via
> nfs4_put_stid() if it is the last reference, but the caller
> subsequently accesses lock_stp->st_mutex and lock_stp->st_stid,
> leading to a use-after-free.
>
> Fix this by moving mutex_unlock() before release_lock_stateid()
> and jumping over the remaining lock_stp cleanup after release,
> since release_lock_stateid() already handles the final put.
> This ensures no further access to lock_stp after it may be freed.
>
> Fixes: 5db1c03feb00 ("nfsd: clean up lockowner refcounting when finding them")
> Cc: stable@vger.kernel.org
> Signed-off-by: Wentao Liang <vulab@iscas.ac.cn>
> ---
> fs/nfsd/nfs4state.c | 7 ++++++-
> 1 file changed, 6 insertions(+), 1 deletion(-)
>
> diff --git a/fs/nfsd/nfs4state.c b/fs/nfsd/nfs4state.c
> index 88c347957da5..cef9d8ddfc43 100644
> --- a/fs/nfsd/nfs4state.c
> +++ b/fs/nfsd/nfs4state.c
> @@ -8388,13 +8388,18 @@ nfsd4_lock(struct svc_rqst *rqstp, struct nfsd4_compound_state *cstate,
> * If this is a new, never-before-used stateid, and we are
> * returning an error, then just go ahead and release it.
> */
> - if (status && new)
> + if (status && new) {
> + mutex_unlock(&lock_stp->st_mutex);
> release_lock_stateid(lock_stp);
> + goto out_no_lock_stp;
> + }
>
> mutex_unlock(&lock_stp->st_mutex);
>
> nfs4_put_stid(&lock_stp->st_stid);
> }
> +
> +out_no_lock_stp:
> if (open_stp)
> nfs4_put_stid(&open_stp->st_stid);
> nfsd4_bump_seqid(cstate, status);
This patch is not correct. It's not terribly obvious, but at the point
of the start of the delta, lock_stp has a refcount of 2, so this
problem can't happen:
1. nfs4_alloc_stid() — sets sc_count = 1
2. init_lock_stateid() line 8193 — refcount_inc(&stp->st_stid.sc_count) → sc_count = 2
I don't think there is a bug here.
--
Jeff Layton <jlayton@kernel.org>
prev parent reply other threads:[~2026-05-18 16:39 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-05-18 15:30 [PATCH] nfsd: fix use-after-free in nfsd4_lock() when releasing new lock stateid Wentao Liang
2026-05-18 16:39 ` Jeff Layton [this message]
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=1013d4caa10d79eeab095ca51cdc4f243d6eb798.camel@kernel.org \
--to=jlayton@kernel.org \
--cc=Dai.Ngo@oracle.com \
--cc=chuck.lever@oracle.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-nfs@vger.kernel.org \
--cc=neil@brown.name \
--cc=okorniev@redhat.com \
--cc=stable@vger.kernel.org \
--cc=tom@talpey.com \
--cc=vulab@iscas.ac.cn \
/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