GPU VulnDB

Database/Kernel, userspace & hypervisor

Linux kernel NFSD: client use-after-free when the laundromat reaps a blocked lock

CVSS 9.8CVE-2026-90036Kernel, userspace & hypervisorcurated

Impact

A lock owner whose only remaining reference is a blocked lock on nn->blocked_locks_lru holds a raw pointer to its nfs4_client with no reference on it. When the per-net laundromat reaps that entry, the final nfs4_put_stateowner() takes the client's cl_lock, but because the laundromat already detached the nbl, __destroy_client() no longer sees it and a concurrent force_expire_client() can free the client first - so cl_lock is dereferenced in freed memory. This is in the in-kernel NFS server, which is how many GPU fleets export home directories and dataset volumes to nodes; a corrupted or panicking file server takes out every job reading from it, and the window is opened by ordinary client lock traffic plus a client expiry. The 9.8/AV:N score is the kernel CNA's blanket value; the flaw is a timing race in server-side state teardown, not a straightforward remote memory-write primitive.

Who can reach it

Remote NFS clients that can take byte-range locks against the server, combined with a client expiry (idle timeout or administrative force-expire). Reachable by anyone permitted to mount an export; no host account on the NFS server is needed.

What to do

Apply the stable-kernel update containing the listed commits and reboot the NFS server nodes; nfsd is in-kernel, so restarting the nfs-server unit does not pick up the fix. Plan a drain of the exports, which on a fileserver means an outage window for every client mounting it. No fixed distribution version is named in the record.

References

Related entries

All Kernel, userspace & hypervisor 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.