CVE-2026-89704
massWriteback error race in Linux kernel nfsd NFSv4.2 COPY causes silent data loss
The Linux kernel's NFS server (nfsd) mishandles writeback error detection during asynchronous NFSv4.2 server-side COPY operations. Because the nfsd file cache reuses a single struct file per inode, a concurrent COMMIT or stable WRITE can advance the destination file's writeback error cursor between the moment a writeback error occurs and the moment the COPY worker samples it, so the error is missed and the copy is incorrectly marked committed (FILE_SYNC4). The client is then told the copied data is durable when it was not, resulting in silent data loss — an integrity flaw (CVSS 7.5) rather than a code-execution bug. Affected systems are those running a Linux kernel with the vulnerable nfsd code and serving NFSv4.2 clients that use server-side COPY, with the race triggered by an attacker with network access to an NFS export or by ordinary concurrent client activity such as backup jobs. No public proof of concept or in-the-wild exploitation is known; the fix is a small upstream patch (sampling the error cursor at the start of the copy) that distributions are expected to backport.
What to do: Patch to a kernel that includes the fix ('nfsd: sample writeback error cursor before async COPY loop') as soon as your distribution ships it in a stable or point release. Until then, reduce risk by limiting concurrent COMMIT/stable-WRITE traffic against files being copied via NFSv4.2 server-side COPY, and verify durability of critical copied data from the client (re-read with checksums or explicit fsync). Audit recent NFSv4.2 COPY operations — especially backups and replication jobs — for undetected corruption or missing data.
| Linux kernel (nfsd, NFSv4.2 server-side COPY) | — |
Order-of-magnitude estimate by the model from install counts, market share and public scan data it knows; verify before quoting.
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().
- Vector
- CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:H/A:N
In the news0 stories
No ingested article mentions this CVE yet.