GPU VulnDB

Database/Kernel, userspace & hypervisor

Linux kernel NFS client: file lock list traversed without nfsi->rwsem, allowing use-after-free on lock structures

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

Impact

nfs_delegation_claim_locks() and nfs4_reclaim_locks() cannot hold flc_lock while iterating the file lock list because lock recovery can block for a long time, and the existing so_delegreturn_mutex is not sufficient since one inode can have several nfs4_state instances. The result is a use-after-free on file lock structures during delegation recall and state recovery; nfs4_locku_done() and nfs4_lock_done() break the same rule by calling locks_lock_inode_wait() without nfsi->rwsem. This fires on NFSv4 clients exactly when the server recalls a delegation or the client recovers state after a server restart or network blip - a routine event on a GPU fleet with shared dataset mounts, and one that hits many nodes at the same moment. Expect kernel memory corruption on the compute node, not a recoverable I/O error.

Who can reach it

Local to the NFS client node, triggered by normal protocol events: a server-side delegation recall or state recovery while byte-range locks are held. A workload that takes file locks on an NFSv4 mount is enough; no attacker privilege on the client is required, and a server operator can induce the condition.

What to do

Apply the stable-kernel fix, which switches both paths to nfsi->rwsem and moves locks_lock_inode_wait() into _nfs4_proc_setlk(). Kernel update plus reboot on each NFS client node - a fleet-wide rolling drain and reboot. No partial mitigation short of avoiding byte-range locks on NFSv4 mounts. No vendor advisory beyond the kernel stable commits is present 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.