GPU VulnDB

Database/Control plane, storage & DevOps

Linux nfsd: lock owner freed by the laundromat while client teardown walks it, causing a NULL dereference

UnscoredCVE-2026-89662Control plane, storage & DevOpscurated

Impact

__destroy_client() releases open owners, but a lock owner whose only reference is a blocked lock stays on cl_ownerstr_hashtbl, and client_has_state() does not count a bare owner - so DESTROY_CLIENTID can reach __destroy_client() with such owners present. It then calls remove_blocked_locks() on each owner without holding a reference, while the per-net laundromat reaps blocked locks from nn->blocked_locks_lru independently; the two paths share blocked_locks_lock only for the list splice, not the owner's lifetime. The laundromat frees the owner as __destroy_client() dereferences it, a NULL dereference in remove_blocked_locks(). On a node exporting NFS to the fleet this is a kernel oops in the server, taking mounts down across every client that depends on it. The fix holds cl_lock across the walk, taking a reference and unhashing each owner first.

Who can reach it

Local to the NFS server host: a race between DESTROY_CLIENTID-driven teardown and the per-net laundromat reaping blocked locks. Ordinary NFSv4 client churn with blocked locks outstanding is enough; no special privilege on the server is described.

What to do

Update the NFS server host to a stable kernel carrying the fix; four backport commits are linked on the record. nfsd is in-kernel, so this is a reboot of the server node with mounts stalled or failed over. Batch with the other nfsd lifetime fixes published the same day rather than taking separate windows.

References

Related entries

All Control plane, storage & DevOps entries

This entry is curated: imported from vendor advisories with machine assistance, not yet individually verified. Confirm against your vendor's advisory before acting, and report anything wrong.