All of lore.kernel.org
 help / color / mirror / Atom feed
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>,
	sashiko-bot <sashiko-bot@kernel.org>
Subject: [PATCH v4 0/9] NFSD: Fix UAFs in client teardown and state revocation
Date: Thu, 09 Jul 2026 13:40:23 -0400	[thread overview]
Message-ID: <20260709-cel-v4-0-1d519d9be0cb@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 v4:
- Fix svc_export double put in nfs4_put_stid() (sashiko)
- Link to v3: https://patch.msgid.link/20260707-cel-v3-0-7c0cc16fd54f@kernel.org

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

Changes in v2:
- Add matching UAF fixes in several other paths

---
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 | 149 ++++++++++++++++++++++++++++++++++++++++++++--------
 2 files changed, 131 insertions(+), 24 deletions(-)
---
base-commit: ee6ae4a6bf3565b880dfb420017337475dfbc9ea
change-id: 20260705-cel-61c1c70caa03

Best regards,
--  
Chuck Lever


             reply	other threads:[~2026-07-09 17:40 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-07-09 17:40 Chuck Lever [this message]
2026-07-09 17:40 ` [PATCH v4 1/9] NFSD: Prevent lock owner use-after-free during client teardown Chuck Lever
2026-07-09 17:40 ` [PATCH v4 2/9] NFSD: Prevent client use-after-free during delegation revoke Chuck Lever
2026-07-09 17:40 ` [PATCH v4 3/9] NFSD: Prevent client use-after-free during admin state revocation Chuck Lever
2026-07-09 17:40 ` [PATCH v4 4/9] NFSD: Prevent client use-after-free during export " Chuck Lever
2026-07-09 17:40 ` [PATCH v4 5/9] NFSD: Prevent client use-after-free during NFSv4.0 revoked-state cleanup Chuck Lever
2026-07-09 17:40 ` [PATCH v4 6/9] NFSD: Consolidate the revocation-path client unpin Chuck Lever
2026-07-09 17:40 ` [PATCH v4 7/9] NFSD: Prevent client use-after-free during blocked-lock reaping Chuck Lever
2026-07-09 18:36   ` Jeff Layton
2026-07-09 17:40 ` [PATCH v4 8/9] NFSD: Prevent client use-after-free during close_lru reaping Chuck Lever
2026-07-09 18:37   ` Jeff Layton
2026-07-09 17:40 ` [PATCH v4 9/9] NFSD: Release the export reference when reaping open stateids Chuck Lever
2026-07-09 18:40   ` Jeff Layton
2026-07-09 19:55     ` 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=20260709-cel-v4-0-1d519d9be0cb@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=sashiko-bot@kernel.org \
    --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.