CVE-2026-89685: nfsd: fix clock domain mismatch in clients_still_reclaiming()
In the Linux kernel, the following vulnerability has been resolved:
nfsd: fix clock domain mismatch in clientsstillreclaiming()
clientsstillreclaiming() computes a deadline from nn->boottime (CLOCKREALTIME, ~1.7 billion) but compares it against ktimegetboottimeseconds() (CLOCKBOOTTIME, seconds since boot). The comparison is always false — it would take ~54 years of uptime for BOOTTIME to exceed the REALTIME-derived deadline.
This means any client can hold the server in grace indefinitely by sending CLAIMPREVIOUS OPEN requests, blocking all non-reclaim operations for all other clients.
Add boottimebt (CLOCKBOOTTIME) alongside the existing boottime and use it for the deadline computation. boottime (CLOCKREALTIME) is preserved for its clboot clientid-nonce role.
Affected Software
Event History
Frequently Asked Questions
Who can exploit this issue?
An NFS client that can send CLAIM_PREVIOUS OPEN requests to the affected NFS server can keep the server in its grace period indefinitely. This blocks non-reclaim operations for other clients.
What conditions indicate that a server may already be affected?
Affected servers can remain in grace far longer than expected while a client continues sending CLAIM_PREVIOUS OPEN requests. During that time, other clients' non-reclaim operations are blocked.
Is there a workaround if the fix cannot be applied immediately?
The provided information identifies the triggering traffic as CLAIM_PREVIOUS OPEN requests from an NFS client. Limiting access to the NFS server to trusted clients can reduce exposure, but no specific configuration workaround is provided.