CVE-2026-89706
High · 7.5CVSS
7.5
EPSS
0.5%
Published
Sep 11, 2026
CISA due date
—
Cloudanix analysis
A Linux NFS server bug can make copied files look safely stored even when the storage step actually failed, creating a hidden risk that important data disappears later.
- Exploitation
- Remote Unauthenticated
- Attacker needs
- None
- Complexity
- Low
- Impact
- Data Tampering
- Component
- OS kernel
- Class
- Other
- Remediation
- Upgrade
- Effort
- Medium
- Patch risk
- Low
What it actually does
Async COPY in nfsd captures the write verifier but fails to rotate nn->writeverf when post-copy vfs_fsync_range or filemap_check_wb_err reports an error; the client then receives NFS_UNSTABLE via CB_OFFLOAD, issues COMMIT, receives the identical verifier, and silently accepts non-durable data, violating the UNSTABLE+COMMIT contract.
Why it matters to the business
NFS servers may deliver copied data that later disappears or is corrupted without any error reported to the client, creating silent integrity failures in distributed file workloads; the issue has low exploitability and is not known to be used in the wild or ransomware campaigns.
How an attack unfolds
An attacker mounts an affected NFS share, performs an async COPY whose writeback later fails, receives an NFS_UNSTABLE CB_OFFLOAD, follows up with COMMIT, obtains the unchanged verifier, and concludes the data is durable when it is not.
How to fix it
Apply the upstream fix that calls nfsd_reset_write_verifier directly from the async COPY worker on durable-storage errors (filtering -EAGAIN and -ESTALE); rebuild and deploy updated kernel packages on all NFS servers.
How to confirm the fix worked
Confirm the patch is present by inspecting nfsd source for the nfsd_reset_write_verifier call in the async COPY failure path; test by forcing writeback errors during COPY and verifying the verifier changes on subsequent COMMIT.
Typical attack path
- Mount an NFSv4.2 share that supports async COPY
- Issue an async COPY operation that triggers writeback failure
- Receive CB_OFFLOAD reporting NFS_UNSTABLE with the original verifier
- Send COMMIT and receive the same verifier value
- Silently drop the copy result believing it succeeded
How to detect it
Search NFS server logs and kthread worker traces for COPY operations that report writeback errors yet leave the write verifier unchanged; correlate client COMMIT requests that receive the same verifier value immediately after an UNSTABLE CB_OFFLOAD.
What your security team should do
- Patch NFS servers with the verifier-reset fix within normal change windows given the absence of known exploitation
- Review NFS copy and commit audit logs for unexpected UNSTABLE responses followed by successful COMMITs
- Ensure clients and servers run matching recent kernels to avoid protocol-edge regressions
The record
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.
Affected packages
| Ecosystem | Package | Introduced | Fixed |
|---|