Description

In the Linux kernel, the following vulnerability has been resolved: NFSD: Prevent lock owner use-after-free during client teardown __destroy_client() releases a client's open owners, but a lock owner whose only reference is a blocked lock (nbl) stays on cl_ownerstr_hashtbl. client_has_state() does not count a bare owner, so DESTROY_CLIENTID can reach __destroy_client() with such owners present. __destroy_client() then walks the table, calling remove_blocked_locks() on each owner without a reference. Freeing a blocked lock drops the owner reference held via flc_owner. The per-net laundromat reaps blocked locks from nn->blocked_locks_lru independently of client state. The two paths share blocked_locks_lock only for the list splice, not the owner's lifetime. The laundromat therefore frees the owner as __destroy_client() dereferences it, a NULL dereference in remove_blocked_locks(). nfsd4_release_lockowner() holds a reference across the same call; __destroy_client() does not. Hold cl_lock across the walk, taking a reference and unhashing each owner, then drop it before remove_blocked_locks() and nfs4_put_stateowner(), which take blocked_locks_lock and cl_lock.

Executive Summary

Technical Details

Mitigations

References

Additional Metadata

{
  "score": "9.8",
  "pubDate": "2026-09-11T20:19:52.523Z",
  "pubdate": "2026-09-11T20:19:52.523Z",
  "executiveSummary": "This vulnerability is a use-after-free (UAF) flaw residing in the Linux kernel's NFSD (NFS server) component, specifically triggered during client teardown procedures.\nThe vulnerability arises from improper reference counting and synchronization when handling lock owners that persist solely due to blocked locks.\nAn unprivileged remote attacker with network access to the NFS service can potentially trigger this condition by initiating a DESTROY_CLIENTID request while a blocked lock is being processed by the laundromat thread.\nSuccessful exploitation may lead to a kernel panic (denial of service) or potential memory corruption, which could theoretically be leveraged for arbitrary code execution depending on memory layout and heap state.\nThe flaw affects the interaction between the client state teardown logic in __destroy_client() and the per-net laundromat responsible for reaping blocked locks.\nThe risk is significant as it involves kernel-level memory corruption in a widely used file system service.\nExploitation requires the existence of a specific race condition between the client destruction path and the blocked locks eviction process.",
  "technicalDetails": "The root cause of the vulnerability is a race condition in the NFSD client teardown process, specifically involving the cleanup of lock owners that are linked to blocked locks (nbl).\nDuring the execution of __destroy_client(), the kernel iterates through the cl_ownerstr_hashtbl to remove client state. However, the logic fails to account for lock owners whose sole reference is maintained by a blocked lock. Because client_has_state() does not count these 'bare' owners, __destroy_client() proceeds with cleanup while these objects remain active in the hash table.\nThe vulnerability is exacerbated by the lack of sufficient locking synchronization between __destroy_client() and the per-net laundromat thread. The laundromat thread independently reaps blocked locks from the nn->blocked_locks_lru list. While both paths share the blocked_locks_lock for list manipulation, this lock is not held for the entire duration of the owner's lifecycle.\nThe attack flow follows these steps: First, a lock owner associated with a blocked lock persists in the hash table during client destruction. Second, __destroy_client() begins walking the hash table and calls remove_blocked_locks() on the owner. Third, the laundromat thread concurrently triggers and frees the blocked lock, which subsequently decrements the owner's reference count. Fourth, because __destroy_client() does not hold a proper reference to the owner during the transition, the laundromat thread's actions lead to a premature freeing of the object. Finally, __destroy_client() attempts to dereference the freed owner object in remove_blocked_locks(), resulting in a NULL dereference or a use-after-free condition.\nThe discrepancy between the lifecycle management in nfsd4_release_lockowner(), which correctly holds a reference across the call, and __destroy_client(), which fails to do so, creates the window for this memory safety violation.\nSuccessful exploitation requires the attacker to influence the timing of the client state destruction relative to the laundromat's periodic cleanup, typically involving high-frequency NFS operations to increase the probability of hitting the race window."
}