Cloudanix VulnDB

CVE-2026-89685

High · 7.5

CVSS

7.5

EPSS

0.4%

Published

Sep 11, 2026

CISA due date

—

Cloudanix analysis

Monitor only SSVC: Track

A bug in the Linux NFS server can let one client keep the server stuck in recovery mode forever, stopping everyone else from using shared files until the system is fixed.

Exploitation
Remote Unauthenticated
Attacker needs
None
Complexity
Low
Impact
Denial Of Service
Component
OS kernel
Class
Denial of service
Remediation
Upgrade
Effort
Medium
Patch risk
Low

What it actually does

clients_still_reclaiming() uses an incompatible clock source when computing the reclaim deadline, causing the check to always evaluate false and allowing any client to extend the NFS grace period indefinitely via repeated CLAIM_PREVIOUS OPEN requests, blocking all non-reclaim file operations.

Why it matters to the business

NFS servers remain stuck in a recovery state for extended periods, preventing legitimate clients from performing normal file access, leading to widespread application outages and service disruption across dependent workloads.

How an attack unfolds

An attacker acting as an NFS client repeatedly issues CLAIM_PREVIOUS OPEN requests during the grace period; because the deadline comparison never succeeds, the server never exits grace, denying non-reclaim operations to all other clients until the server is restarted or the kernel is updated.

How to fix it

Update the Linux kernel to a version containing the fix that introduces boot_time_bt (CLOCK_BOOTTIME) and uses it for the reclaim deadline computation while preserving the existing boot_time field.

How to confirm the fix worked

Confirm the presence of the corrected clients_still_reclaiming() logic that compares ktime_get_boottime_seconds() against the new boot_time_bt value; test that the grace period expires normally after the expected reclaim window when no further reclaim requests arrive.

Typical attack path

  1. attacker mounts the target NFS export as a client
  2. attacker issues repeated CLAIM_PREVIOUS OPEN requests before the grace period would normally expire
  3. server's clients_still_reclaiming() check fails due to clock mismatch and extends the grace window
  4. non-reclaim operations from all other clients are rejected for the duration of the extended grace period

How to detect it

Review NFS server logs for repeated CLAIM_PREVIOUS OPEN requests that coincide with prolonged grace-period indicators; examine kernel boot and NFSd reclaim counters for anomalies indicating the deadline comparison never succeeding.

What your security team should do

  • Prioritize kernel updates on all NFS servers within the next maintenance window
  • Monitor for unusually long grace periods or repeated CLAIM_PREVIOUS traffic from any single client
  • Consider temporarily disabling NFSv4 reclaim functionality if an immediate kernel update is not feasible

The record

In the Linux kernel, the following vulnerability has been resolved: nfsd: fix clock domain mismatch in clients_still_reclaiming() clients_still_reclaiming() computes a deadline from nn->boot_time (CLOCK_REALTIME, ~1.7 billion) but compares it against ktime_get_boottime_seconds() (CLOCK_BOOTTIME, 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 CLAIM_PREVIOUS OPEN requests, blocking all non-reclaim operations for all other clients. Add boot_time_bt (CLOCK_BOOTTIME) alongside the existing boot_time and use it for the deadline computation. boot_time (CLOCK_REALTIME) is preserved for its cl_boot clientid-nonce role.

Affected packages

Ecosystem Package Introduced Fixed