CVE-2026-89686
Summary
by MITRE • 09/11/2026
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.
If you want to get the best quality for vulnerability data then you always have to consider VulDB.
Analysis
by VulDB Data Team • 09/11/2026
The vulnerability identified as CVE-2024-something (specifically related to nfsd4_alloc_layout_stateid) represents a critical race condition within the Linux kernel's NFS server implementation, specifically affecting the handling of file layouts and delegation revocations. This flaw arises from an inconsistency in locking discipline during the allocation of layout state identifiers for delegated files. In normal operation, when a client holds a delegation on a file, subsequent operations such as LAYOUTGET rely on accessing specific file information structures to validate the request and allocate necessary resources. The function nfsd4_alloc_layout_stateid is responsible for this initialization process but contains a critical oversight where it accesses the fi_deleg_file pointer without acquiring the corresponding fi_lock mutex. This lack of synchronization creates a window of vulnerability where concurrent operations can modify or clear the underlying data structure, leading to system instability and potential denial of service conditions.
The technical root cause lies in the interaction between client-initiated delegation recalls and the kernel's internal laundromat mechanism responsible for cleaning up stale delegations. When two NFS clients interact with the same file, one holding a delegation while another opens it to force a recall, the server initiates a revocation process if the first client does not respond promptly. The laundromat thread then executes this revocation under fi_lock protection, which safely clears the fi_deleg_file pointer within the file information structure. However, because nfsd4_alloc_layout_stateid accesses this same pointer without holding fi_lock in the SC_TYPE_DELEG code path, it may read a NULL value that was cleared by the concurrent revoke operation. This null dereference triggers a BUG_ON assertion failure, causing an immediate kernel panic and resulting in a complete denial of service for all NFS services on the affected system.
From an operational impact perspective, this vulnerability allows any networked client with access to the NFS server to trigger a remote code execution equivalent event leading to system crash. The attack vector is straightforward: an attacker can establish a delegation on a file and then have another entity open that same file to force a recall. By ensuring the first client does not respond to the recall notification, the laundromat will eventually revoke the delegation. If a LAYOUTGET request arrives during this narrow timing window using the original delegation stateid, the race condition is exploited. This makes the vulnerability particularly dangerous as it requires no authentication beyond standard NFS access and can be triggered repeatedly by multiple clients, effectively allowing for a persistent denial of service attack against critical storage infrastructure relying on Linux-based NFS servers.
The remediation strategy involves correcting the locking discipline to ensure atomicity in accessing shared data structures. The fix mandates acquiring fi_lock around the read operation of fi_deleg_file within the SC_TYPE_DELEG path, thereby aligning it with the protective measures already present in the find_any_file() arm of the codebase. This synchronization prevents concurrent modifications from invalidating the pointer during critical evaluation phases. Furthermore, rather than relying on a fatal BUG_ON assertion that crashes the kernel upon detecting an inconsistent state, the patch replaces this behavior with a graceful error return mechanism. This allows the system to clean up any partially initialized layout stateid resources and report an appropriate error code to the client, maintaining system stability even when race conditions occur due to high concurrency or malicious timing attacks.
This vulnerability maps directly to CWE-362: Concurrent Execution using Shared Resource with Improper Synchronization (Race Condition), as the core issue is the unsynchronized access to a shared resource leading to an inconsistent state. Additionally, it aligns with ATT&CK technique T1499: Endpoint Denial of Service, specifically under sub-techniques involving service exhaustion or system crash via exploitation of software vulnerabilities. The incident highlights the importance of rigorous locking strategies in kernel-level network services where concurrent access patterns are common and predictable by external actors. Administrators must ensure that their Linux kernels are updated to include this patch, as unpatched systems remain vulnerable to remote denial-of-service attacks through standard NFS protocol interactions without requiring elevated privileges or complex exploitation chains beyond precise timing manipulation of delegation states.