GPU VulnDB

Database/Kernel, userspace & hypervisor

Linux kernel nfsd: clock-domain mismatch lets one client hold the server in grace indefinitely

CVSS 7.5CVE-2026-89685Kernel, userspace & hypervisorcurated

Impact

The grace-period deadline is computed from nn->boot_time (CLOCK_REALTIME) but compared against ktime_get_boottime_seconds() (CLOCK_BOOTTIME), so the comparison never becomes true short of about 54 years of uptime. The escape hatch that is supposed to end a stuck grace period is therefore dead code, and a single client sending CLAIM_PREVIOUS OPEN requests can keep the server in grace forever, blocking all non-reclaim operations for every other client. On a shared GPU cluster that is one tenant freezing everyone else's dataset and checkpoint I/O after any server restart, with no way out but another restart.

Who can reach it

Any NFSv4 client permitted to mount the export, after a server reboot or restart - it only has to keep issuing CLAIM_PREVIOUS OPENs. Authentication is whatever the export requires; no elevated privilege.

What to do

Update the host kernel to a stable release that adds the CLOCK_BOOTTIME boot_time_bt and uses it for the deadline, then reboot the NFS server. There is no runtime knob that restores the timeout; restarting nfsd only restarts the grace period.

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.