GPU VulnDB

Database/Control plane, storage & DevOps

Linux kernel NFSv4 client: a delayed FREE_STATEID can use a freed nfs_server

CVE-2026-74730Control plane, storage & DevOpscurated

Impact

If a FREE_STATEID operation is delayed for any reason, the struct nfs_server it references can be cleaned up while the call is still in flight, giving a use-after-free; the fix pins the object for the duration of the call. The reporter hit this in practice, and the record does not establish anything beyond a crash. GPU nodes routinely mount NFS for datasets, checkpoints and home directories, so the blast radius is a node panic during mount teardown or server trouble, which on a collective training job means every rank restarts from the last checkpoint.

Who can reach it

No authentication story - this is a normal NFSv4 client code path. Reaching it needs a FREE_STATEID that is delayed, which in practice means a slow, wedged or hostile NFS server, concurrent with teardown of the mount. Whoever operates the NFS server is in a position to create that timing.

What to do

Update to a stable kernel carrying the refcount fix and reboot; the NFS client is in-kernel, so there is no daemon to restart. Because this shows up around mount teardown and server stalls, the practical interim is keeping NFS servers healthy and avoiding forced unmounts under load - it does not remove the race.

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.