CVE-2026-98682

In the Linux kernel, the following vulnerability has been resolved:

smb: client: drain and invalidate before server-side copy/clone

cifs file copychunk range() and the clone (FICLONE) path of cifs remap file range() do not serialise the destination page cache against the server-side copy the way the other server-side range operations (smb3 zero range(), smb3 punch hole(), smb3 collapse range() and smb3 insert range()) do.

cifs file copychunk range() invalidates the destination range with filemap invalidate inode(), which takes and drops the mapping's invalidate lock internally, so the lock is no longer held when the copychunk ioctl is issued. It also never drains in-flight netfs I/O on the target. The clone path never takes the invalidate lock at all (only i rwsem), uses a bare truncate inode pages range() and likewise does not drain outstanding I/O.

As a result an asynchronous destination writeback can complete after the server-side copy/clone has run and reinstate stale data over the region just written by the server, corrupting the file. This is the same class of corruption as commit d7d2adcd022b ("smb/client: flush dirty data before punching a hole") and has been seen randomly in generic/363 against Windows Server.

Fix both paths to follow the established ordering: hold the target mapping's invalidate lock across the flush and invalidation of the destination and the server ioctl, and call netfs wait for outstanding io() on the target to drain in-flight writes before the ioctl is issued. Only the target inode's invalidate lock is required, as the source is merely flushed and not invalidated; i rwsem (already held via lock two nondirectories()) is acquired before the invalidate lock, matching the VFS lock ordering. Since filemap invalidate inode() takes that same lock internally, replace it with its own unmap/flush/invalidate steps instead of calling it, and return early on a zero-length copy to avoid a range underflow.