kernel/git/stable/linux.git/fs/nfsd, branch linux-rolling-stable

xdrgen: Emit a blank line ahead of enum declarations

2026-09-14T11:40:35+00:00

[ Upstream commit ec5a7c2dceb09caf36262ecbd633eb7d4f9e4d3d ] Clean up. The declaration templates for structs, pointers, and typedefs each begin with a blank line, which keeps successive declarations and the include block above them visually separated. The enum declaration template omits that blank line. trim_blocks collapses the template's lone comment line to nothing, so the omission stayed invisible as long as every generated header happened to lead with a non-enum declaration. Fixes: 4329010ad9c3 ("xdrgen: Address some checkpatch whitespace complaints") Link: https://patch.msgid.link/20260712193122.116845-2-cel@kernel.org Signed-off-by: Chuck Lever Signed-off-by: Sasha Levin

lockd: Regenerate NLMv4 XDR code

2026-09-14T11:40:35+00:00

[ Upstream commit e1d6e968ee26eee9654e35cd8141e38cefe307a4 ] The checked-in NLMv4 xdrgen output predates the addition of enum value validation to generated decoders. As a result the decoders for fsh4_mode, fsh4_access, and nlm4_stats still accept any 32-bit value, while the current generator rejects values outside the enumeration. Resync the generated files with the in-tree xdrgen by regenerating from the unchanged nlm4.x specification. This is a plain regeneration with no specification change; it also refreshes the recorded specification modification time to show that all existing enum decoders have picked up the xdrgen tool fix. Reviewed-by: Jeff Layton Link: https://patch.msgid.link/20260630155638.874492-1-cel@kernel.org Signed-off-by: Chuck Lever Stable-dep-of: ec5a7c2dceb0 ("xdrgen: Emit a blank line ahead of enum declarations") Signed-off-by: Sasha Levin

nfsd: add protocol support for CB_NOTIFY

2026-09-14T11:40:35+00:00

[ Upstream commit a0ac2a63d4b21455985436fbc70192da14a163fd ] Add the necessary bits to nfs4_1.x and remove the duplicate definitions from nfs4.h and the uapi nfs4 header. Regenerate the xdr files. Note that regenerating these files caused conflicts with the definitions of NFS4_VERIFIER_SIZE and NFS4_FHSIZE in include/uapi/linux/nfs4.h. These constants are defined by the RFC, and are not part of the kernel API. They have been removed. Userspace consumers who require those constants should plan to get them from more authoritative sources. The nfsstat4 enum defined in the .x is fed to the xdrgen-generated wire encoder and decoder, which treat every enumerated value as legal on the wire. Do not carry the NFS4ERR_FIRST_FREE sentinel (which is not a protocol error code) into the .x; keeping it would make 10097 a value that could leak onto the wire. Instead base nfsd's internal error codes (NFSERR_EOF and friends) at an impossible nfsstat4 value, as lockd does for its nlm__int__* status codes. Signed-off-by: Jeff Layton Link: https://patch.msgid.link/20260616-dir-deleg-v7-2-6cbc7eac0ade@kernel.org Signed-off-by: Chuck Lever Stable-dep-of: ec5a7c2dceb0 ("xdrgen: Emit a blank line ahead of enum declarations") Signed-off-by: Sasha Levin

NFSD: Release the export reference when reaping open stateids

2026-09-14T11:40:35+00:00

[ Upstream commit 6480bd703684ed3f760e9e36c4a699033c0806ae ] nfs4_put_stid() releases the svc_export tracked in nfs4_stid.sc_export, but free_ol_stateid_reaplist() frees open and lock stateids by calling ->sc_free() directly, bypassing that path. An open stateid takes an sc_export reference in nfs4_open() and a lock stateid takes its own in init_lock_stateid(); both reach free_ol_stateid_reaplist() through their normal teardown, the open stateid via release_open_stateid() and the lock stateid via nfsd4_release_lockowner(), each through put_ol_stateid_locked(). The reference is therefore never dropped, pinning the export and blocking unmount for the lifetime of the stateid. Release sc_export in free_ol_stateid_reaplist() the way nfs4_put_stid() does. ->sc_free() runs once per stateid, and a stateid reaches free_ol_stateid_reaplist() or nfs4_put_stid() but never both, so the reference is dropped exactly once. Revoked stateids reach this path with sc_export already cleared by drop_stid_export(), so they are skipped rather than double-freed. nfs4_put_stid() itself read sc_export before acquiring cl_lock. drop_stid_export() clears that field and releases the reference under cl_lock, so a concurrent revocation could drop the export in the window between the read and the final put, releasing the same reference twice. Read sc_export while cl_lock is held so the two paths serialize and the reference is released exactly once. Fixes: ba0cde5dc81d ("NFSD: Track svc_export in nfs4_stid") Reported-by: sashiko-bot Closes: https://sashiko.dev/#/patchset/20260707-cel-v3-0-7c0cc16fd54f@kernel.org?part=9 Reviewed-by: Jeff Layton Link: https://patch.msgid.link/20260709-cel-v4-9-1d519d9be0cb@kernel.org Signed-off-by: Chuck Lever Signed-off-by: Sasha Levin

NFSD: Prevent client use-after-free during blocked-lock reaping

2026-09-11T09:50:45+00:00

[ Upstream commit 9026932ac8be4d0ae01db47f23619a98cc57b671 ] A bare lock owner -- its only remaining reference a blocked lock on nn->blocked_locks_lru -- holds a raw pointer to its nfs4_client but no reference keeping the client alive. When the per-net laundromat reaps such a lock, freeing the nbl drops the owner reference held through flc_owner, and the final nfs4_put_stateowner() takes the client's cl_lock. Because the laundromat detaches the nbl first, __destroy_client() no longer finds it, so a concurrent force_expire_client() can free the client before nfs4_put_stateowner() runs, dereferencing cl_lock in freed memory. Pin the client with cl_rpc_users before dropping nn->blocked_locks_lock, and skip clients already expiring, whose blocked locks __destroy_client() frees while holding an owner reference. Take nn->client_lock outside nn->blocked_locks_lock. Every other site holds nn->blocked_locks_lock as a leaf, acquiring no further lock, so placing nn->client_lock outside it cannot form a lock-order cycle. Fixes: 7919d0a27f1e ("nfsd: add a LRU list for blocked locks") Cc: stable@vger.kernel.org Reviewed-by: Jeff Layton Link: https://patch.msgid.link/20260709-cel-v4-7-1d519d9be0cb@kernel.org Signed-off-by: Chuck Lever Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman

NFSD: Prevent client use-after-free during close_lru reaping

2026-09-11T09:50:45+00:00

[ Upstream commit 2330b788d732f43668b965b3105b37ceb276dfea ] An nfs4_openowner left on nn->close_lru after its final CLOSE keeps its last closed stateid in oo_last_closed_stid, holding only a raw pointer to its nfs4_client. The laundromat reaps timed-out entries, drops nn->client_lock, and calls nfs4_put_stid(), which dereferences the client through cl_lock. Nothing pins the client across that window, so a concurrent force_expire_client() can free it and nfs4_put_stid() reads freed memory. __destroy_client() hits the same race, walking clp->cl_openowners without cl_lock. Pin the client with cl_rpc_users before dropping client_lock, and skip clients already expiring. __destroy_client() then cleans up its own close_lru entries through release_last_closed_stateid(), so teardown no longer races the laundromat. Fixes: 217526e7ecc9 ("nfsd: protect the close_lru list and oo_last_closed_stid with client_lock") Cc: stable@vger.kernel.org Reviewed-by: Jeff Layton Link: https://patch.msgid.link/20260709-cel-v4-8-1d519d9be0cb@kernel.org Signed-off-by: Chuck Lever Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman

NFSD: Consolidate the revocation-path client unpin

2026-09-11T09:50:45+00:00

[ Upstream commit 3308cf3f11ed23c79f9f3f90b34bbbad3e3a6ea9 ] The client use-after-free fixes in the state-revocation paths left four open-coded copies of one idiom: drop a cl_rpc_users pin without renewing the client's lease, waking force_expire_client() when the last pin drops on a client it is tearing down. The accompanying "do not renew" rationale was documented at only one of the four sites. put_client_renew_locked() and put_client_renew() already carry the same pin-drop logic, but they renew a non-expired client's lease and so would resurrect the client whose state is being revoked. Factor the common pin-drop into __put_client_locked(), parameterized by whether to renew. The renew helpers pass true; the new put_client_no_renew_locked() and put_client_no_renew() pass false and carry the revocation paths, which must not revive the client they are tearing down. No change in behavior. Reviewed-by: NeilBrown Reviewed-by: Jeff Layton Link: https://patch.msgid.link/20260709-cel-v4-6-1d519d9be0cb@kernel.org Signed-off-by: Chuck Lever Stable-dep-of: 2330b788d732 ("NFSD: Prevent client use-after-free during close_lru reaping") Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman

NFSD: Prevent client use-after-free during export state revocation

2026-09-11T09:50:45+00:00

[ Upstream commit 2108de53568a64936a0da3e04d85c35df98d3fb6 ] nfsd4_revoke_export_states() has the same use-after-free as nfsd4_revoke_states(): it drops nn->client_lock across revoke_one_stid() and the following read of clp->cl_minorversion, but the stateid reference it holds does not pin the client. A teardown racing the dropped lock can free the client while revoke_one_stid() still dereferences it. exportfs -u drives this path through NFSD_CMD_UNLOCK_EXPORT, so an administrator removing an export can race a client expiry. Skip a client that is already expiring and otherwise pin it with cl_rpc_users under client_lock before dropping the lock, matching nfsd4_revoke_states(). Fixes: 2eac189bb059 ("NFSD: Add NFSD_CMD_UNLOCK_EXPORT netlink command") Reviewed-by: NeilBrown Reviewed-by: Jeff Layton Link: https://patch.msgid.link/20260709-cel-v4-4-1d519d9be0cb@kernel.org Signed-off-by: Chuck Lever Stable-dep-of: 2330b788d732 ("NFSD: Prevent client use-after-free during close_lru reaping") Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman

NFSD: Guard admin state-revocation walks with NFSD_NET_UP

2026-09-11T09:50:45+00:00

[ Upstream commit 2f3e6638aebc0ab8afb8b4e9816ea9a1cad85378 ] Writing to /proc/fs/nfsd/unlock_filesystem, or sending the NFSD_CMD_UNLOCK_FILESYSTEM or NFSD_CMD_UNLOCK_EXPORT netlink command, walks the NFSv4 client hash tables to revoke open state and cancel async COPY operations. All three handlers gate that walk on nn->nfsd_serv, but a listener added via portlist or netlink listener_set sets nn->nfsd_serv before any nfsd thread starts. nfsd_startup_net() has not yet allocated nn->conf_id_hashtbl, so the walkers dereference a NULL table. A local administrator with CAP_SYS_ADMIN can crash the kernel this way without ever starting the server. nn->nfsd_serv is set when the service is created, which precedes table allocation. NFSD_NET_UP instead brackets the window where the tables are live: set at the end of nfsd_startup_net() and cleared in nfsd_shutdown_net() after they are freed, both under nfsd_mutex. Gating the three unlock paths on NFSD_NET_UP fixes the startup-time NULL dereference while preserving the earlier post-shutdown use-after-free fix. Reported-by: XIAO WU Fixes: 1ac3629bf012 ("nfsd: prepare for supporting admin-revocation of state") Cc: stable@vger.kernel.org Reviewed-by: Jeff Layton Link: https://patch.msgid.link/20260621162551.2469460-1-cel@kernel.org Signed-off-by: Chuck Lever Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman

NFSD: Annotate caller preconditions for the state-table walkers

2026-09-11T09:50:44+00:00

[ Upstream commit 5f367f05481d56be90f8c13eee4cb421cd7af2d8 ] The state-table walkers now assert nfsd_mutex with lockdep_assert_held() and document the nfsd_mutex / nn->nfsd_serv precondition in a Context: kdoc section, so the next caller added to this path cannot silently reintroduce the same use-after-free. Reviewed-by: Jeff Layton Link: https://patch.msgid.link/20260613-unlock-filesystem-uaf-v1-3-462b9bec8c84@kernel.org Signed-off-by: Chuck Lever Stable-dep-of: 2f3e6638aebc ("NFSD: Guard admin state-revocation walks with NFSD_NET_UP") Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman