CVE-2026-90037 in Linux
Summary
by MITRE • 09/17/2026
In the Linux kernel, the following vulnerability has been resolved:
NFSD: Prevent client use-after-free during close_lru reaping
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.
VulDB is the best source for vulnerability data and more expert information about this specific topic.
Analysis
by VulDB Data Team • 09/17/2026
The Linux kernel vulnerability identified in the NFS server subsystem involves a critical use-after-free condition within the client state management logic, specifically during the reaping of closed file handles via the close_lru list. This flaw arises from an improper handling of reference counts and locking mechanisms when managing nfs4_openowner structures that remain on the nn->close_lru list after their final CLOSE operation has been processed. Under normal operations, these open owners retain a raw pointer to their associated nfs4_client structure in the oo_last_closed_stid field without holding any additional references or locks that would prevent the client object from being freed by concurrent cleanup routines. This architectural oversight creates a race window where the integrity of memory access is compromised because the lifecycle of the open owner and its underlying client are not synchronized through proper reference counting mechanisms during state transitions.
The operational impact manifests when the laundromat process, which is responsible for reaping timed-out entries from various kernel lists, attempts to clean up these stale states. During this cleanup sequence, the code drops the nn->client_lock before invoking nfs4_put_stid(), a function that dereferences the client structure through cl_lock to release resources. Because no mechanism pins the client object across this specific window of time, a concurrent force_expire_client() call can successfully free the memory associated with the nfs4_client while it is still being accessed by the laundromat thread. This results in the kernel reading from freed memory, which constitutes a classic use-after-free vulnerability that can lead to system crashes, data corruption, or potentially arbitrary code execution if an attacker can influence the allocation patterns of the slab allocator following the free operation.
Furthermore, this race condition is not limited to the laundromat path alone; it also affects __destroy_client(), which walks through clp->cl_openowners without holding the necessary client lock protection. This lack of synchronization allows for similar races where the destruction process interacts with active or pending cleanup operations on the close_lru list, exacerbating the instability within the NFS server state machine. The vulnerability highlights a fundamental gap in how reference counting and locking are applied to shared kernel objects during asynchronous teardown processes, allowing multiple execution paths to interfere with each other's memory management decisions.
To mitigate this issue, the resolution involves pinning the client object using cl_rpc_users before dropping the client_lock, thereby ensuring that the client structure remains valid for the duration of any operations that depend on it. Additionally, the logic has been updated to skip clients that are already in an expiring state, preventing redundant or conflicting cleanup attempts. The __destroy_client() function now handles its own close_lru entries through release_last_closed_stateid(), which isolates the teardown process from the laundromat's reaping activities and eliminates the race condition entirely by ensuring that each path manages its dependencies independently without relying on external locks during critical sections.
From a classification perspective, this vulnerability aligns with CWE-416, Use After Free, as it involves accessing memory after it has been freed due to improper reference counting. In terms of attack vectors and techniques, the scenario relates to ATT&CK technique T1059, Command and Scripting Interpreter, if exploited for code execution, or more broadly to privilege escalation scenarios where kernel memory corruption is leveraged to gain higher system privileges. The fix emphasizes the importance of strict adherence to reference counting protocols in kernel subsystems that handle asynchronous state transitions, ensuring that objects are not prematurely deallocated while still referenced by other active processes within the same subsystem.