GPU VulnDB

Database/Control plane, storage & DevOps

Linux kernel nfsd: async COPY samples the writeback error cursor late and reports failed copies as durable

CVSS 7.5CVE-2026-89704Control plane, storage & DevOpscurated

Impact

_nfsd_copy_file_range() sampled dst->f_wb_err after the copy loop. Because the nfsd file cache shares one struct file per inode, a concurrent COMMIT or stable WRITE can advance the cursor first, so the COPY worker sees no error, sets NFSD4_COPY_F_COMMITTED, and CB_OFFLOAD encodes FILE_SYNC4. The client then treats data whose writeback actually failed as durable - silent data loss with no error surfaced anywhere. On a GPU fleet the exposure is checkpoints and dataset copies performed server-side: a job resumes from a checkpoint that was never written. Integrity impact, not a crash, which is why it is easy to miss in monitoring.

Who can reach it

Not an attack in the usual sense - it is triggered by concurrent NFSv4.2 COPY and COMMIT/WRITE traffic from ordinary authenticated clients against the same file, combined with a real storage writeback failure. No special privileges are needed.

What to do

Update the NFS server kernel to a build with the fix (stable commits 20a67a7d1822, 52b2db7a72e1, 8277d4a11ae2, a1cbafe756cd) and reboot the node. There is no mitigation short of the patch; disabling NFSv4.2 server-side copy on clients avoids the path but is a client-side workaround only. Where writeback errors have occurred on an affected server, treat server-side-copied checkpoints from that window as unverified.

References

Related entries

All Control plane, storage & DevOps entries

This entry is curated: imported from vendor advisories with machine assistance, not yet individually verified. Confirm against your vendor's advisory before acting, and report anything wrong.