CVE-2026-89685: Linux Kernel NFS DOS Vulnerability

CVE-2026-89685 Overview

A denial-of-service vulnerability affects the NFS server (nfsd) subsystem in the Linux kernel. The flaw resides in the clients_still_reclaiming() function, which compares timestamps from two incompatible clock domains. The function derives a deadline from nn->boot_time (CLOCK_REALTIME) but compares it against ktime_get_boottime_seconds() (CLOCK_BOOTTIME). The comparison never evaluates true under realistic uptimes, allowing a malicious NFS client to hold the server in grace state indefinitely by issuing CLAIM_PREVIOUS OPEN requests. This blocks all non-reclaim operations for every other client connected to the server.

Critical Impact
A single NFS client can indefinitely stall file service for all other clients by exploiting the grace-period logic, producing a network-reachable, unauthenticated denial of service against the NFS server.

Affected Products

Linux kernel nfsd subsystem (upstream)
Distributions shipping vulnerable kernel versions prior to the referenced fix commits
NFSv4 servers exposed to untrusted or semi-trusted clients

Discovery Timeline

2026-09-11 - CVE-2026-89685 published to NVD
2026-09-13 - Last updated in NVD database

Technical Details for CVE-2026-89685

Vulnerability Analysis

The NFSv4 protocol uses a grace period after server restart during which clients reclaim previously held state via CLAIM_PREVIOUS OPEN operations. The kernel enforces a deadline for this grace period through clients_still_reclaiming(). The function's role is to end the grace period once the deadline passes, restoring normal service to all clients.

The defect is a clock-domain mismatch. The deadline is calculated from nn->boot_time, which uses CLOCK_REALTIME and holds a value around 1.7 billion seconds (Unix epoch). The current-time reading uses ktime_get_boottime_seconds(), which returns CLOCK_BOOTTIME expressed as seconds since system boot. Because boot-time seconds will not exceed a realtime epoch value for roughly 54 years of continuous uptime, the deadline check always returns false. The server therefore never determines that the grace period has expired as long as a client keeps reclaiming.

An attacker with NFS access continuously issues CLAIM_PREVIOUS OPEN requests. Non-reclaim operations from other clients are blocked, producing a persistent denial of service on the file service.

Root Cause

The root cause is inconsistent use of clock domains within a single comparison. boot_time is retained for its role as the cl_boot clientid nonce, which legitimately requires CLOCK_REALTIME. The upstream fix introduces boot_time_bt populated from CLOCK_BOOTTIME and uses it exclusively for deadline arithmetic, aligning both sides of the comparison to the same monotonic clock.

Attack Vector

Exploitation requires network reachability to the NFS server and the ability to establish an NFSv4 session. No authentication is required beyond what the server itself demands for a mount. The attacker sends a sustained stream of CLAIM_PREVIOUS OPEN requests during the grace window, preventing the server from ever exiting grace state. All other clients then encounter NFS4ERR_GRACE responses for non-reclaim operations, resulting in service outage.

No exploitation code is required beyond a modified NFSv4 client. See the Kernel Git Commit Fix for the corrected logic.

Detection Methods for CVE-2026-89685

Indicators of Compromise

Prolonged NFS grace period on the server that does not terminate within the configured nfsd grace timeout
Large volume of CLAIM_PREVIOUS OPEN operations originating from a single client or small set of clients
Legitimate NFS clients receiving repeated NFS4ERR_GRACE responses long after server startup
Kernel log absence of the expected grace-period termination message from nfsd

Detection Strategies

Monitor nfsd grace state via /proc/fs/nfsd and alert when the grace period exceeds the configured lease time by a wide margin
Correlate rpc.nfsd operation counters to identify clients producing disproportionate CLAIM_PREVIOUS volume
Capture NFSv4 traffic with tshark or tcpdump and analyze the ratio of reclaim operations to standard OPEN requests per client

Monitoring Recommendations

Track kernel version and patch level across NFS servers to confirm remediation status of CVE-2026-89685
Alert on client-reported NFS4ERR_GRACE errors persisting beyond the expected grace window
Baseline typical grace-period duration after planned reboots and flag deviations

How to Mitigate CVE-2026-89685

Immediate Actions Required

Apply the upstream kernel fix that introduces boot_time_bt for grace-deadline arithmetic
Restrict NFS server exposure to trusted networks using firewall rules or VPN segmentation until patches are deployed
Audit which clients hold NFSv4 state and identify any producing unexpected reclaim traffic

Patch Information

The fix is available in the mainline and stable kernel trees. Review the corresponding commits: Kernel Git Commit Update, Kernel Git Commit Fix, and Kernel Git Commit Security. Distribution-specific kernel updates should be applied through the vendor's package manager once available.

Workarounds

Limit NFS server access to authenticated, trusted network segments via iptables, nftables, or dedicated VLAN separation
Enable Kerberos (sec=krb5) authentication on NFSv4 exports to prevent unauthenticated clients from issuing reclaim traffic
Reduce the nfsd lease time via /proc/fs/nfsd/nfsv4leasetime to shorten the maximum grace window as a partial mitigation

bash

# Configuration example: restrict NFS to a trusted subnet and shorten lease time
# 1. Firewall NFS to a trusted CIDR only
nft add rule inet filter input ip saddr != 10.0.0.0/24 tcp dport 2049 drop

# 2. Reduce NFSv4 lease time (must be set before nfsd starts)
echo 30 > /proc/fs/nfsd/nfsv4leasetime

# 3. Restart nfsd to apply
systemctl restart nfs-server