CVE-2026-89704: nfsd: sample writeback error cursor before async COPY loop
In the Linux kernel, the following vulnerability has been resolved:
nfsd: sample writeback error cursor before async COPY loop
nfsdcopyfilerange() samples dst->fwberr into "since" after the copy loop, then uses it to detect writeback errors via filemapcheckwberr() once vfsfsyncrange() returns. Because the nfsdfile cache reuses a single struct file across requests targeting the same inode, a concurrent COMMIT or stable WRITE on dst advances dst->fwberr to the current mapping->wberr via filecheckandadvancewberr() during its own vfsfsyncrange(). If that advancement lands between the writeback error appearing in mapping->wberr and the COPY worker sampling "since", the worker captures the already-advanced cursor, errseqcheck() sees cur == since and returns zero, and NFSD4COPYFCOMMITTED is set even though writeback failed. CBOFFLOAD then encodes wrstablehow = FILESYNC4, 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 filemapcheckwberr() detects any error that occurs during the copy regardless of which thread first observes it. This matches the pattern used by nfsdvfswrite() and nfsd4clonefilerange().
Affected Software
Event History
Frequently Asked Questions
Which NFS workloads are exposed to the race?
The race requires an asynchronous NFSv4 COPY targeting a destination inode while another request targeting that same inode performs a COMMIT or stable WRITE. The shared nfsd file cache can cause those requests to use the same struct file and writeback-error cursor.
What is the operational impact if the race occurs?
A writeback failure from the COPY can be missed, causing the server to report the copy as committed. The client may treat the copied data as durable even though writeback failed, resulting in silent data loss.