GPU VulnDB

Database/Kernel, userspace & hypervisor

Linux kernel nfsd: unchecked client reference in SETCLIENTID_CONFIRM leads to use-after-free

CVSS 7.8CVE-2025-38724Kernel, userspace & hypervisorcurated

Impact

An in-kernel NFS server does not check the return of get_client_locked() in nfsd4_setclientid_confirm(), so a SETCLIENTID_CONFIRM that races with a confirmed client expiring proceeds without holding a reference and can later touch freed memory. On a node that exports knfsd - a scratch or dataset share in front of a GPU fleet, or a head node re-exporting shared storage - any client that can mount is in a position to drive that race, and a use-after-free in nfsd means kernel memory corruption or a panic that takes the export down for every job reading from it. NVD rates this as local privilege escalation (AV:L, CVSS 7.8); the trigger path is NFSv4 protocol traffic from a client, so treat the exposure as whoever is in your export list. Nodes that do not run nfsd are unaffected regardless of kernel version.

Who can reach it

An NFSv4 client that can reach the server's nfsd and issue SETCLIENTID_CONFIRM. No local account on the server is required; whether credentials are needed depends on the export's auth flavour. Hosts that do not export NFS are not exposed.

What to do

Take the stable kernel fix for your series (commits linked in the record) or the distribution kernel that carries it. A kernel update means draining the node and rebooting it, which on a GPU host means evicting running training or inference work; if you cannot schedule that yet, the interim mitigation is to stop exporting NFS from the affected host or restrict the export list to trusted clients. No fixed release version is stated in the record beyond the listed commits.

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.