CVE-2026-89640: cifs: fix loff_t underflow in cifs_remap_file_range() when len == 0
In the Linux kernel, the following vulnerability has been resolved:
cifs: fix lofft underflow in cifsremapfilerange() when len == 0
With len == 0 (clone to EOF), the effective length is computed as:
len = srcinode->isize - off;
If off > isize, this is a negative lofft, corrupting the ByteCount in the FSCTLDUPLICATEEXTENTSTOFILE request and inverting the range in filemapwriteandwaitrange(). The existing off >= isize check fires only after the ioctl has already been sent.
Snapshot isizeread() once for both the bounds check and the length calculation, eliminating the TOCTOU and 32-bit torn-read risk. Reject off > srcsize with -EINVAL. Treat off == srcsize as a no-op, consistent with genericremapfilerangeprep().
Affected Software
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Upgrade
Upgrade
debian/linuxto a version that resolves this vulnerability.Fixed in 6.1.190-1 - Upgrade
Upgrade
debian/linuxto a version that resolves this vulnerability.Fixed in 6.12.111-1 - Upgrade
Upgrade
debian/linuxto a version that resolves this vulnerability.Fixed in 7.2.6-1 - Upgrade
Upgrade
debian/linux-6.12to a version that resolves this vulnerability.Fixed in 6.12.111-1~deb12u1 - Upgrade
Upgrade
linux/Kernelto a version that resolves this vulnerability.Fixed in 5.10.273 - Upgrade
Upgrade
linux/Kernelto a version that resolves this vulnerability.Fixed in 5.15.224 - Upgrade
Upgrade
linux/Kernelto a version that resolves this vulnerability.Fixed in 6.1.188 - Upgrade
Upgrade
linux/Kernelto a version that resolves this vulnerability.Fixed in 6.6.157 - Upgrade
Upgrade
linux/Kernelto a version that resolves this vulnerability.Fixed in 6.12.109 - Upgrade
Upgrade
linux/Kernelto a version that resolves this vulnerability.Fixed in 6.18.50 - Upgrade
Upgrade
linux/Kernelto a version that resolves this vulnerability.Fixed in 7.2.4 - Upgrade
Upgrade
debian/linuxto a version that resolves this vulnerability.Fixed in 6.1.190-1Fixed in 6.12.115-2Fixed in 7.2.12-1Fixed in 7.2.15-1 - Upgrade
Upgrade
debian/linux-6.12to a version that resolves this vulnerability.Fixed in 6.12.113-1~deb12u1 - Upgrade
Upgrade
ubuntu/linux-hwe-7.0to a version that resolves this vulnerability.Fixed in 7.0.0-42.42~24.04.1 - Upgrade
Upgrade
ubuntu/linux-riscv-7.0to a version that resolves this vulnerability.Fixed in 7.0.0-42.42.1~24.04.1 - Upgrade
Upgrade
ubuntu/linuxto a version that resolves this vulnerability.Fixed in 7.0.0-42.42 - Upgrade
Upgrade
ubuntu/linux-awsto a version that resolves this vulnerability.Fixed in 7.0.0-1016.17 - Upgrade
Upgrade
ubuntu/linux-gcpto a version that resolves this vulnerability.Fixed in 7.0.0-1016.18 - Upgrade
Upgrade
ubuntu/linux-ibmto a version that resolves this vulnerability.Fixed in 7.0.0-1017.17 - Upgrade
Upgrade
ubuntu/linux-oem-7.0to a version that resolves this vulnerability.Fixed in 7.0.0-1017.17 - Upgrade
Upgrade
ubuntu/linux-oracleto a version that resolves this vulnerability.Fixed in 7.0.0-1015.16 - Upgrade
Upgrade
ubuntu/linux-riscvto a version that resolves this vulnerability.Fixed in 7.0.0-42.42.1 - Compensating control
In cifs_remap_file_range(), snapshot src_inode->i_size with i_size_read() once for both bounds checking and length calculation; reject off > src_size with -EINVAL, and treat off == src_size as a no-op.
Event History
Frequently Asked Questions
What operation and input condition trigger the flaw?
The issue is triggered in cifs_remap_file_range() when a clone-to-EOF operation uses len == 0 and the source offset is greater than the source file size. The resulting negative effective length can corrupt the ByteCount in the FSCTL_DUPLICATE_EXTENTS_TO_FILE request.
What happens when the source offset is exactly at EOF?
An offset equal to the source file size is treated as a no-op, consistent with __generic_remap_file_range_prep(). An offset beyond EOF is rejected with -EINVAL.
Why does the fix read the source size only once?
Using one i_size_read() result for both validation and length calculation prevents a time-of-check/time-of-use race. It also avoids a torn read risk on 32-bit systems.