Description

In the Linux kernel, the following vulnerability has been resolved: nfsd: fix BUG_ON in nfsd4_alloc_layout_stateid on racing delegation revoke nfsd4_alloc_layout_stateid reads fp->fi_deleg_file without holding fi_lock when the parent stateid is a delegation. A concurrent delegation revoke via the laundromat can clear fi_deleg_file under fi_lock, causing nfsd_file_get() to return NULL and triggering the BUG_ON. This race is client-reachable: two NFS clients can trigger it by having one hold a delegation while another opens the same file to force a recall. When the first client doesn't respond to the recall, the laundromat revokes it. A concurrent LAYOUTGET from any client using the delegation stateid hits the race window. Fix this by taking fi_lock around the fi_deleg_file read in the SC_TYPE_DELEG path, matching the locking discipline of the find_any_file() arm, and replacing the BUG_ON with a graceful error return that cleans up the partially-initialized layout stateid.

Executive Summary

Technical Details

Mitigations

References

Additional Metadata

{
  "score": "9.8",
  "pubDate": "2026-09-11T20:19:55.533Z",
  "pubdate": "2026-09-11T20:19:55.533Z",
  "executiveSummary": "A race condition vulnerability has been identified in the Linux kernel's nfsd (NFS server) component, specifically within nfsd4_alloc_layout_stateid.\nThe vulnerability occurs due to unsynchronized access to the fi_deleg_file pointer during the processing of delegation stateids, leading to a NULL pointer dereference that triggers a kernel BUG_ON.\nThis flaw allows a remote attacker to induce a denial-of-service (DoS) condition by crashing the kernel through specifically crafted NFS operations.\nThe attack is client-reachable and requires multiple NFS clients to coordinate file access, causing a delegation revocation to race against a LAYOUTGET operation.\nSuccessful exploitation results in an immediate system panic, rendering the NFS server unresponsive.\nThe issue affects the nfsd subsystem responsible for managing pNFS (Parallel NFS) layout stateids and delegation state management.",
  "technicalDetails": "The vulnerability originates in the nfsd4_alloc_layout_stateid function, which performs a read operation on fp->fi_deleg_file without acquiring the required fi_lock spinlock when dealing with SC_TYPE_DELEG (delegation) stateids.\nThe root cause is a race condition between the nfsd4_alloc_layout_stateid function and the laundromat thread responsible for revoking NFS delegations.\nIn the vulnerable state, the laundromat thread can execute concurrently to clear the fi_deleg_file pointer while holding the fi_lock. Because the former function accesses this pointer without holding the lock, it may read a stale or NULL pointer.\nWhen nfsd_file_get() is subsequently called with this nullified or invalid pointer, it returns NULL, which violates the assumptions made by nfsd4_alloc_layout_stateid, ultimately triggering a BUG_ON and crashing the kernel.\nThe attack flow follows a predictable pattern: 1) An NFS client acquires a delegation on a file. 2) A second client initiates an open operation on the same file, forcing the server to issue a recall to the first client. 3) If the first client fails to respond, the server's laundromat thread initiates a revocation process to clear the delegation state, including the fi_deleg_file pointer. 4) A concurrent LAYOUTGET request sent by an attacker (or the client) attempts to allocate a layout stateid that references the delegation currently being torn down. 5) The race window is hit, the null pointer is dereferenced, and the kernel panics.\nThis exploit is reachable remotely over the network, as it leverages standard NFS protocol interactions (OPEN, LAYOUTGET, and revocation cycles). No specific elevated privileges are required beyond the ability to interact with the NFS server as a client.\nThe fix addresses the issue by enforcing strict locking discipline: acquiring fi_lock before reading the delegation file pointer in the SC_TYPE_DELEG path. Furthermore, the kernel now gracefully handles the NULL pointer return by returning an error to the caller rather than invoking BUG_ON, ensuring system stability despite the racing condition."
}