CVE-2026-89706: nfsd: Reset write verifier when async COPY writeback fails
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 CBOFFLOAD after the worker kthread completes. When the post-copy vfsfsyncrange() or filemapcheckwberr() in nfsdcopyfilerange() reports an error, the worker correctly leaves NFSD4COPYFCOMMITTED clear so that CBOFFLOAD encodes wrstablehow as NFSUNSTABLE, but the server's write verifier is not rotated.
A client that receives NFSUNSTABLE in CBOFFLOAD follows up with COMMIT to make the copied data durable. With the verifier unchanged, COMMIT returns the same value the client just received via CBOFFLOAD, 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 nfsdvfswrite() and nfsdcommit().
Rotate nn->writeverf at the writeback-failure site. The async COPY worker has no svcrqst, so commitresetwriteverifier() is not available here; calling nfsdresetwriteverifier() directly mirrors the trace-less reset already used by nfsdfilecheckwriteerror() for the same purpose. Filter out -EAGAIN and -ESTALE, matching commitresetwriteverifier(), since neither indicates a durable-storage failure.
Affected Software
Event History
Frequently Asked Questions
Which systems are exposed to this issue?
Linux kernel NFS servers using nfsd asynchronous COPY operations are affected when post-copy writeback reports an error through vfs_fsync_range() or filemap_check_wb_err(). The issue concerns the server-side handling of the asynchronous COPY completion.
Under what circumstances can data be silently treated as durable?
The condition occurs when an asynchronous COPY writeback fails, the server reports NFS_UNSTABLE in CB_OFFLOAD, and the client subsequently sends COMMIT. If the write verifier has not changed, the client can interpret the matching verifier returned by COMMIT as confirmation that the copied data is durable even though the writeback failed.
What does the fix change?
The fix rotates the NFS server write verifier at the asynchronous COPY writeback-failure site. This prevents a later COMMIT from returning the same verifier and incorrectly confirming durability after a failed writeback.