CVE-2026-89706
largeLinux kernel nfsd async COPY write-verifier flaw causes silent data loss
The Linux kernel's NFS server (nfsd) fails to rotate its write verifier when the writeback or fsync step of an asynchronous NFSv4.2 server-side COPY fails. The client is correctly told via CB_OFFLOAD that the data is NFS_UNSTABLE and dutifully sends COMMIT, but because the verifier was never rotated, COMMIT returns the same value the client already holds, so the client concludes the copy is durable when the data was in fact silently lost. This breaks the UNSTABLE+COMMIT durability contract of RFC 7862 section 15.1 and RFC 8881 section 18.32, and typically manifests when storage writeback fails (e.g., I/O errors, disk-full conditions) rather than through deliberate attacker action, though the CVSS 3.1 base score of 7.5 reflects high integrity impact over the network with no privileges. Any Linux system running nfsd for NFSv4.2 clients that use server-side COPY is affected until the kernel fix is applied. No public proof of concept is known, the issue is not in the CISA KEV catalog, and no exploitation has been reported.
What to do: Update to a kernel release containing the nfsd fix that calls nfsd_reset_write_verifier() on async COPY writeback failure (excluding -EAGAIN and -ESTALE), and apply the corresponding vendor firmware/kernel updates on NAS appliances that repackage the kernel. Monitor NFS servers for writeback and fsync errors (kernel logs, nfsd stats) since those are the trigger conditions for silent data loss. Until patched, consider disabling NFSv4.2 server-side COPY or having clients verify copied data independently after COMMIT.
| Linux kernel (nfsd, NFSv4.2 async 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: Reset write verifier when async COPY writeback fails Async COPY captures nn->writeverf at request time and reports it to the client via CB_OFFLOAD after the worker kthread completes. When the post-copy vfs_fsync_range() or filemap_check_wb_err() in _nfsd_copy_file_range() reports an error, the worker correctly leaves NFSD4_COPY_F_COMMITTED clear so that CB_OFFLOAD encodes wr_stable_how as NFS_UNSTABLE, but the server's write verifier is not rotated. A client that receives NFS_UNSTABLE in CB_OFFLOAD follows up with COMMIT to make the copied data durable. With the verifier unchanged, COMMIT returns the same value the client just received via CB_OFFLOAD, and the client concludes the copy is durable -- silently dropping the data whose writeback in fact failed. This violates the UNSTABLE+COMMIT durability contract (RFC 7862 section 15.1, RFC 8881 section 18.32) and matches the bug just fixed in nfsd_vfs_write() and nfsd_commit(). Rotate nn->writeverf at the writeback-failure site. The async COPY worker has no svc_rqst, so commit_reset_write_verifier() is not available here; calling nfsd_reset_write_verifier() directly mirrors the trace-less reset already used by nfsd_file_check_write_error() for the same purpose. Filter out -EAGAIN and -ESTALE, matching commit_reset_write_verifier(), since neither indicates a durable-storage failure.
- 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.