Cloudanix VulnDB

CVE-2026-89704

High · 7.5

CVSS

7.5

EPSS

0.5%

Published

Sep 11, 2026

CISA due date

—

Cloudanix analysis

Next patch cycle SSVC: Track

A timing flaw in the Linux file server can cause copied files to be reported as safely saved when they were not, risking unnoticed data loss.

Exploitation
Remote Unauthenticated
Attacker needs
None
Complexity
Moderate
Impact
Data Tampering
Component
OS kernel
Class
Race Condition
Remediation
Upgrade
Effort
Medium
Patch risk
Low

What it actually does

Race condition in nfsd _nfsd_copy_file_range allows a concurrent COMMIT or stable WRITE on the destination to advance the writeback error cursor after an error appears in mapping->wb_err but before the COPY worker samples "since", causing errseq_check to return zero, NFSD4_COPY_F_COMMITTED to be set, and CB_OFFLOAD to report FILE_SYNC4 even though writeback failed.

Why it matters to the business

Organizations running NFS servers face risk of silent data corruption or loss during file copies, with clients incorrectly treating failed writes as durable; the issue affects Linux kernel deployments using async COPY operations and may require urgent patching in high-availability or data-integrity environments.

How an attack unfolds

An attacker with network access to an NFSv4 server triggers an async COPY to a destination inode while simultaneously issuing COMMIT or stable WRITE operations on the same inode; timing the operations so the error cursor is advanced between error appearance and sampling allows the server to falsely report successful durable writeback to the client, resulting in undetected data loss.

How to fix it

Upgrade the Linux kernel to a version containing the fix that samples the writeback error cursor once at the start of _nfsd_copy_file_range before any writes; apply the patch that aligns nfsd COPY error handling with the pattern used by nfsd_vfs_write and nfsd4_clone_file_range.

How to confirm the fix worked

After patching, confirm the kernel source contains the updated _nfsd_copy_file_range that samples dst->f_wb_err into "since" at function entry, then verify via code review or runtime testing that filemap_check_wb_err detects errors regardless of concurrent fsync activity on the same file.

Typical attack path

  1. Establish NFSv4 mount and issue async COPY request targeting shared inode
  2. Concurrently issue COMMIT or stable WRITE on same destination to advance wb_err
  3. Force or wait for writeback error to appear in mapping->wb_err during COPY
  4. Receive CB_OFFLOAD with FILE_SYNC4 indicating false success
  5. Client proceeds as if data is durable while actual writeback failure is masked

How to detect it

Examine nfsd server logs and kernel traces for concurrent COPY, COMMIT, and WRITE operations on the same inode around writeback error events; look for mismatched filemap_check_wb_err results or unexpected FILE_SYNC4 reports in CB_OFFLOAD callbacks in packet captures or nfsd debug output.

What your security team should do

  • Prioritize kernel updates for all NFS servers handling async COPY workloads
  • Monitor nfsd-related patches in upcoming stable kernel releases
  • Review NFSv4 client behavior around COPY and COMMIT durability guarantees
  • Consider disabling async COPY features temporarily if patching is delayed in critical environments

The record

In the Linux kernel, the following vulnerability has been resolved: nfsd: sample writeback error cursor before async COPY loop _nfsd_copy_file_range() samples dst->f_wb_err into "since" after the copy loop, then uses it to detect writeback errors via filemap_check_wb_err() once vfs_fsync_range() returns. Because the nfsd_file cache reuses a single struct file across requests targeting the same inode, a concurrent COMMIT or stable WRITE on dst advances dst->f_wb_err to the current mapping->wb_err via file_check_and_advance_wb_err() during its own vfs_fsync_range(). If that advancement lands between the writeback error appearing in mapping->wb_err and the COPY worker sampling "since", the worker captures the already-advanced cursor, errseq_check() sees cur == since and returns zero, and NFSD4_COPY_F_COMMITTED is set even though writeback failed. CB_OFFLOAD then encodes wr_stable_how = FILE_SYNC4, the client treats the copied data as durable, and the failure becomes silent data loss. Sample since once at the start of the function. The cursor then reflects state in effect before this COPY issues any writes, and filemap_check_wb_err() detects any error that occurs during the copy regardless of which thread first observes it. This matches the pattern used by nfsd_vfs_write() and nfsd4_clone_file_range().

Affected packages

Ecosystem Package Introduced Fixed