KernelScan.io

HIGH

nfsd AsyncCopy Verifier

CVE-2026-89706

CVSS 7.5 / 10.0 NVD

CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:H/A:N

KernelScan AI6.4MEDIUM

01

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.

02

Engine v0.6.0

Risk summary

An NFS client can silently lose data after an async server-side copy if writeback fails. The server fails to rotate its write verifier on the error, so the client's follow-up COMMIT sees the same verifier and wrongly concludes the data is durable. Any NFSv4.2 client using server-side copy against a vulnerable nfsd server is affected.

Affectedfs/nfsd/nfs4proc.c (nfsd)

Vulnerability analysis

When an async server-side COPY operation encounters a writeback failure, the server correctly reports the data as unstable to the client, but leaves its write verifier unchanged. The client later issues COMMIT to confirm durability; because the verifier matches the one already seen, the client treats the data as committed and silently drops its local copy, even though the server-side writeback failed. The fix rotates the write verifier on writeback failure so the client receives a different value and recognizes the data was not durably stored. Any NFSv4.2 client performing a server-side copy against a vulnerable server can reach this; no special privileges beyond normal client access are required.

03

BranchIntroducedFixed inPatch commit
5.15—5.15.221c6d2f6372c7e
6.6—6.6.1576b13d26cc21b
6.12—6.12.10931d4d0a62ec4
6.18—6.18.50591134e059e3
7.2—7.2.4bf0cd31a9abc
6.1—6.1.1888a08ffe73eb2
5.105.10.2205.10.270cc5f7cef0659
mainline—7.3-rc1f5cb2276954c
cip/6.12—6.12.111-cip3231d4d0a62ec4