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

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

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

cifsfilecopychunkrange() and the clone (FICLONE) path of cifsremapfilerange() do not serialise the destination page cache against the server-side copy the way the other server-side range operations (smb3zerorange(), smb3punchhole(), smb3collapserange() and smb3insertrange()) do.

cifsfilecopychunkrange() invalidates the destination range with filemapinvalidateinode(), which takes and drops the mapping's invalidatelock 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 invalidatelock at all (only irwsem), uses a bare truncateinodepagesrange() 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 invalidatelock across the flush and invalidation of the destination and the server ioctl, and call netfswaitforoutstandingio() on the target to drain in-flight writes before the ioctl is issued. Only the target inode's invalidatelock is required, as the source is merely flushed and not invalidated; irwsem (already held via locktwonondirectories()) is acquired before the invalidatelock, matching the VFS lock ordering. Since filemapinvalidateinode() 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.