From: Chuck Lever <cel@kernel.org>
To: 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>
Cc: linux-nfs@vger.kernel.org, Wolfgang Walter <linux@stwm.de>,
Chuck Lever <cel@kernel.org>
Subject: [PATCH v3 0/9] NFSD: Fix UAFs in client teardown and state revocation
Date: Tue, 07 Jul 2026 15:31:20 -0400 [thread overview]
Message-ID: <20260707-cel-v3-0-7c0cc16fd54f@kernel.org> (raw)
An NFSv4 stateid, and a bare lock owner reachable through the client's
owner hash, hold only a raw pointer to the owning nfs4_client. That
client outlives its state only because __destroy_client() drains every
stateid and owner before free_client() runs. A walk that dereferences
the client, or the owner, through one of those raw pointers after
dropping the lock that kept it reachable races a concurrent teardown
that can free it first. The NULL-pointer dereference reported during
client teardown was one such race; auditing the pattern found more
across the revocation and laundromat-reaping paths.
Where the racing object is the client, the fix is uniform: pin it with
cl_rpc_users across the window in which nn->client_lock is dropped.
Skipping a client that is already expiring is part of the correctness
argument, not cleanup. force_expire_client() stops consulting
cl_rpc_users once its wait has passed, so a pin taken then would not
hold the client; the walk must instead leave that client's state for
its own teardown to drain. Testing the expiry and taking the pin under
nn->client_lock is what makes the choice atomic against the expiry.
Pinning the client from these paths introduces a lock-order edge that
did not exist before: nn->client_lock now nests outside the inner
region of nn->deleg_lock and outside nn->blocked_locks_lock, both leaf
acquisitions everywhere else. The nesting is one-directional, and
netns.h records the deleg_lock relationship; a reaping path added later
must take nn->client_lock first.
Two changes sit apart from the lifetime races. The revocation and
reaping fixes left four open-coded copies of the pin-drop idiom,
consolidated here into put_client_no_renew() helpers (patch 6). The
same audit turned up an unrelated svc_export leak:
free_ol_stateid_reaplist() reaps open and lock stateids through
->sc_free() directly, bypassing the reference drop nfs4_put_stid()
performs, so the export stays pinned and blocks unmount (patch 9).
---
Changes in v2:
- Add matching UAF fixes in several other paths
---
Changes in v3:
- Fix client UAF in laundromat blocked-lock reaping (Neil)
- Fix client UAF in laundromat close_lru reaping (sashiko)
- Fix svc_export leak when reaping open stateids (sashiko)
- Link to v2: https://patch.msgid.link/20260705-cel-v2-0-d88c3b68e8bc@kernel.org
---
Chuck Lever (9):
NFSD: Prevent lock owner use-after-free during client teardown
NFSD: Prevent client use-after-free during delegation revoke
NFSD: Prevent client use-after-free during admin state revocation
NFSD: Prevent client use-after-free during export state revocation
NFSD: Prevent client use-after-free during NFSv4.0 revoked-state cleanup
NFSD: Consolidate the revocation-path client unpin
NFSD: Prevent client use-after-free during blocked-lock reaping
NFSD: Prevent client use-after-free during close_lru reaping
NFSD: Release the export reference when reaping open stateids
fs/nfsd/netns.h | 6 ++-
fs/nfsd/nfs4state.c | 145 ++++++++++++++++++++++++++++++++++++++++++++--------
2 files changed, 128 insertions(+), 23 deletions(-)
---
base-commit: ee6ae4a6bf3565b880dfb420017337475dfbc9ea
change-id: 20260705-cel-61c1c70caa03
Best regards,
--
Chuck Lever
next reply other threads:[~2026-07-07 19:31 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-07-07 19:31 Chuck Lever [this message]
2026-07-07 19:31 ` [PATCH v3 1/9] NFSD: Prevent lock owner use-after-free during client teardown Chuck Lever
2026-07-07 19:31 ` [PATCH v3 2/9] NFSD: Prevent client use-after-free during delegation revoke Chuck Lever
2026-07-07 19:31 ` [PATCH v3 3/9] NFSD: Prevent client use-after-free during admin state revocation Chuck Lever
2026-07-07 19:31 ` [PATCH v3 4/9] NFSD: Prevent client use-after-free during export " Chuck Lever
2026-07-07 19:31 ` [PATCH v3 5/9] NFSD: Prevent client use-after-free during NFSv4.0 revoked-state cleanup Chuck Lever
2026-07-07 19:31 ` [PATCH v3 6/9] NFSD: Consolidate the revocation-path client unpin Chuck Lever
2026-07-07 19:31 ` [PATCH v3 7/9] NFSD: Prevent client use-after-free during blocked-lock reaping Chuck Lever
2026-07-07 19:31 ` [PATCH v3 8/9] NFSD: Prevent client use-after-free during close_lru reaping Chuck Lever
2026-07-07 19:31 ` [PATCH v3 9/9] NFSD: Release the export reference when reaping open stateids 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=20260707-cel-v3-0-7c0cc16fd54f@kernel.org \
--to=cel@kernel.org \
--cc=Dai.Ngo@oracle.com \
--cc=jlayton@kernel.org \
--cc=linux-nfs@vger.kernel.org \
--cc=linux@stwm.de \
--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