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
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.