GPU VulnDB

Database/Control plane, storage & DevOps

Linux kernel nfsd: use-after-free when writing v4_end_grace races with server shutdown

CVSS 7.8CVE-2026-22980Control plane, storage & DevOpscurated

Impact

Writing to the nfsd v4_end_grace control file can race with NFS server shutdown, freeing and then accessing nfsd state - reclaim_str_hashtbl in particular. The fix adds a client_tracking_active flag under nn->client_lock so the laundromat work item is never rescheduled after shutdown has waited for it. On a GPU fleet this lands on the NFS servers that export home directories, datasets and checkpoints: a crash there stalls every training job holding an open file. The trigger requires writing to a privileged nfsd control file, so this is an operational-stability and local-root-adjacent bug rather than something a tenant reaches.

Who can reach it

Local and privileged on the NFS server: a process able to write /proc/fs/nfsd/v4_end_grace (root, or the nfsdcltrack upcall path) while nfsd is being shut down. Not reachable from NFS clients or tenant pods.

What to do

Update the NFS server kernel to a build with the nfsd v4_end_grace locking fix (commits in the record) and reboot the server, which for a single-homed NFS export means a storage outage window for every job mounting it. Until patched, avoid scripting v4_end_grace writes around nfsd restarts. The record names no fixed release beyond the listed commits.

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.