Description

In the Linux kernel, the following vulnerability has been resolved: NFSD: Prevent client use-after-free during NFSv4.0 revoked-state cleanup nfs40_clean_admin_revoked() takes a stateid reference under clp->cl_lock, drops nn->client_lock, and calls nfsd4_drop_revoked_stid(), which dereferences the stateid's client through s->sc_client->cl_lock. The stateid reference does not pin the client, so a teardown racing the dropped lock can free the client while nfsd4_drop_revoked_stid() is still using it. This cleanup runs from the laundromat, so a periodic sweep can race force_expire_client() driven by a write to the clients/<id>/ctl file. 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().

Executive Summary

Technical Details

Mitigations

References

Additional Metadata

{
  "score": "9.8",
  "pubDate": "2026-09-11T20:19:52.063Z",
  "pubdate": "2026-09-11T20:19:52.063Z",
  "executiveSummary": "This vulnerability is a use-after-free (UAF) flaw residing in the Linux kernel's NFSD (NFS server) implementation, specifically within the NFSv4.0 revoked-state cleanup mechanism.\nThe issue stems from improper object lifecycle management during the cleanup process, where a stateid reference fails to maintain a valid reference to the parent client structure.\nA race condition exists between the laundromat process, which performs periodic state cleanup, and the force_expire_client function, which can be triggered by a write to the clients/<id>/ctl file.\nIf successfully exploited, an attacker could trigger a use-after-free condition leading to kernel memory corruption, potential local privilege escalation, or a system-wide denial-of-service (kernel panic).\nExploitation requires the ability to interact with the NFS server and influence the state cleanup process while concurrently forcing client expiration. The vulnerability poses a significant risk to the stability and security of systems hosting NFSv4.0 exports.",
  "technicalDetails": "The root cause of the vulnerability lies in the function nfs40_clean_admin_revoked(), which handles the cleanup of revoked stateids for NFSv4.0 clients. During the execution of this function, the kernel takes a reference to a stateid while holding clp->cl_lock. However, it subsequently releases the global nn->client_lock to call nfsd4_drop_revoked_stid().\nWithin nfsd4_drop_revoked_stid(), the kernel attempts to dereference the stateid's associated client structure via s->sc_client->cl_lock. The critical flaw is that the held stateid reference does not pin the parent client structure in memory. Because the cleanup is performed by the laundromat process, a concurrent race condition can occur if a separate administrative action—specifically a write to the clients/<id>/ctl file—triggers force_expire_client() at the exact same moment.\nThe attack flow proceeds as follows: First, the laundromat service identifies revoked stateids and initiates the cleanup process. Second, the attacker, or a system management process, triggers a forced expiration of the target client via the sysfs/ctl interface. Third, as nfs40_clean_admin_revoked() releases the client lock, the force_expire_client() function proceeds to finalize the teardown and deallocation of the client structure.\nBecause the reference to the client was not sufficiently incremented or 'pinned' (using mechanisms like cl_rpc_users), the memory previously allocated for the client structure is freed while nfsd4_drop_revoked_stid() is still attempting to access it. This results in a classic use-after-free scenario where the kernel operates on dangling pointers. The attempt to acquire the lock on a freed object or dereference its members leads to indeterminate state, likely causing a kernel oops, memory corruption, or controlled code execution if the freed memory is subsequently reclaimed by another kernel subsystem.\nThe vulnerable component is the NFSD state management logic within the Linux kernel. This issue affects any kernel configuration where NFSv4.0 support is enabled and the laundromat process is actively managing revoked stateids. There is no requirement for external network packets beyond standard NFS protocol interaction to trigger the state cleanup process, though the specific timing of the race condition makes successful exploitation non-deterministic and complex."
}