CVE-2026-89704 in Linux
Summary
by MITRE • 09/11/2026
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().
If you want to get best quality of vulnerability data, you may have to visit VulDB.
Analysis
by VulDB Data Team • 09/11/2026
The vulnerability resides within the Linux kernel's Network File System server implementation, specifically in the asynchronous file range copy operation handled by _nfsd_copy_file_range. The core technical flaw is a race condition involving the sampling of writeback error cursors during concurrent operations on shared inode structures. In NFSv4 implementations utilizing CB_OFFLOAD or async COPY commands, the kernel reuses a single struct file object within the nfsd_file cache for multiple requests targeting the same destination inode. This architectural optimization introduces a critical synchronization gap where the state of writeback errors is not isolated per operation but rather reflects the global state of the underlying filesystem mapping at any given moment during execution.
The specific failure mechanism occurs when the function samples the dst->f_wb_err cursor into a local variable named since after initiating the copy loop, yet before checking for completion via vfs_fsync_range(). During this interval, if another concurrent thread executes a COMMIT or stable WRITE operation on the same destination file, it triggers its own vfs_fsync_range() call. This secondary operation advances dst->f_wb_err to match the current mapping's wb_err status through file_check_and_advance_wb_err(). If this advancement happens after writeback errors have occurred but before the original COPY worker samples the since variable, a race condition is created where the cursor values align incorrectly. Specifically, errseq_check() compares the current error sequence against the sampled since value and finds them equal because both reflect the post-advancement state rather than the pre-copy baseline.
This logical error results in filemap_check_wb_err returning zero, indicating no errors occurred during the writeback process. Consequently, the NFS server sets NFSD4_COPY_F_COMMITTED to true, signaling that all data has been successfully flushed and persisted on disk. The CB_OFFLOAD response then encodes wr_stable_how as FILE_SYNC4, instructing the client application that the copied data is durable and safe from loss in the event of a system crash or power failure. Because the server incorrectly reports success despite underlying writeback failures, clients proceed with operations assuming data integrity, leading to silent data corruption or permanent data loss without any error notification being returned to the user space applications relying on this guarantee.
This vulnerability aligns with CWE-362, Concurrent Execution using Shared Resource with Improper Synchronization of Separate Threads, as it involves a race condition in accessing shared state (the writeback error cursor) without adequate locking or atomic sampling mechanisms. Furthermore, from an ATT&CK perspective, the exploitation vector relates to T1485 Data Destruction, specifically through silent data loss caused by false integrity assurances provided by compromised storage subsystems. The impact is severe because it undermines the fundamental reliability guarantees of networked file systems, potentially causing catastrophic data inconsistency in enterprise environments where NFS is used for critical database or application storage.
The resolution involves restructuring _nfsd_copy_file_range to sample the since cursor exactly once at the very beginning of the function execution, prior to issuing any write operations. This ensures that the baseline state reflects conditions existing before the COPY command initiated its work, allowing filemap_check_wb_err() to accurately detect any errors that arise during the copy process regardless of concurrent modifications by other threads. This approach mirrors established patterns used in nfsd_vfs_write and nfsd4_clone_file_range, which already implement correct synchronization for similar operations. By aligning this function with existing best practices, the kernel eliminates the race window where error states could be masked by subsequent advancements to the writeback cursor, thereby restoring accurate reporting of data durability status to NFS clients.