CVE-2026-89640

The Linux kernel's CIFS/SMB client contains a signed 64-bit length (loff_t) underflow in cifs_remap_file_range(), the code path used when userspace clones or copies a file range on a mounted CIFS share. When a clone request specifies len == 0 (meaning 'duplicate to end of file'), the kernel computes the effective length as the source file's size minus the requested offset; if that offset lies beyond the file's size, the value goes negative, which corrupts the ByteCount of the FSCTL_DUPLICATE_EXTENTS_TO_FILE command sent to the SMB server and inverts the range passed to filemap_write_and_wait_range(), with a time-of-check/time-of-use gap and a possible torn 32-bit read of the file size aggravating the bug. Any local unprivileged user on a machine with a CIFS mount can trigger it via an ordinary copy_file_range()/remap-style syscall, causing high integrity and availability impact (corrupted data in the destination file and potential client misbehavior) but no confidentiality impact, reflected in the local-vector CVSS 3.1 score of 7.1. The fix snapshots i_size_read() once for both the bounds check and the length calculation, rejects offsets greater than the source size with -EINVAL, and treats an offset equal to the source size as a no-op. No public proof-of-concept or real-world exploitation is known, and the issue is not on CISA's KEV list.

What to do: Apply kernel updates from your distribution that include the upstream cifs fix (the commit that snapshots i_size_read() once and returns -EINVAL for off > src_size, tracked as CVE-2026-89640 in Ubuntu, Red Hat, Debian, and SUSE advisories). Until patched, restrict unprivileged local accounts on multi-user hosts that mount CIFS/SMB shares, since the attack vector is local with low privileges required. Watch for copy_file_range()/clone operations against CIFS-mounted files with offsets beyond end-of-file as a sign of tampering attempts.