The overflow check in rw_verify_area() can itself overflow when
pos + count > LLONG_MAX, causing the sum to wrap to a negative value
and incorrectly return -EINVAL.

This can be reproduced easily by creating a 20 MB file and reading it
via splice() and a size of 0x7FFFFFFFFF000000. The syscall fails
when the file pos reaches 16 MB.

splice(3, NULL, 6, NULL, 9223372036837998592, 0) = 262144
splice(3, NULL, 6, NULL, 9223372036837998592, 0) = 262144
splice(3, NULL, 6, NULL, 9223372036837998592, 0) = -1 EINVAL (Invalid argument)

This can probably be triggered in other ways given that coreutils often
uses SSIZE_MAX as size argument[1][2]

[1] https://cgit.git.savannah.gnu.org/cgit/coreutils.git/tree/src/cat.c?h=v9.9#n505
[2] https://cgit.git.savannah.gnu.org/cgit/coreutils.git/tree/src/copy-file-data.c?h=v9.9#n130
---
 fs/read_write.c | 10 +++++++---
 1 file changed, 7 insertions(+), 3 deletions(-)

diff --git a/fs/read_write.c b/fs/read_write.c
index 833bae068770..8cb4f5bba592 100644
--- a/fs/read_write.c
+++ b/fs/read_write.c
@@ -464,9 +464,13 @@ int rw_verify_area(int read_write, struct file *file, const loff_t *ppos, size_t
 				return -EINVAL;
 			if (count >= -pos) /* both values are in 0..LLONG_MAX */
 				return -EOVERFLOW;
-		} else if (unlikely((loff_t) (pos + count) < 0)) {
-			if (!unsigned_offsets(file))
-				return -EINVAL;
+		} else {
+			/* Clamp count to MAX_RW_COUNT for overflow check. */
+			loff_t end = min_t(loff_t, count, MAX_RW_COUNT);
+			if (unlikely(end > LLONG_MAX - pos)) {
+				if (!unsigned_offsets(file))
+					return -EINVAL;
+			}
 		}
 	}
 
-- 
2.52.0

Il giorno ven 19 dic 2025 alle ore 13:53 Matteo Croce
<technoboy85@gmail.com> ha scritto:
>
> The overflow check in rw_verify_area() can itself overflow when
> pos + count > LLONG_MAX, causing the sum to wrap to a negative value
> and incorrectly return -EINVAL.
>
> This can be reproduced easily by creating a 20 MB file and reading it
> via splice() and a size of 0x7FFFFFFFFF000000. The syscall fails
> when the file pos reaches 16 MB.
>
> splice(3, NULL, 6, NULL, 9223372036837998592, 0) = 262144
> splice(3, NULL, 6, NULL, 9223372036837998592, 0) = 262144
> splice(3, NULL, 6, NULL, 9223372036837998592, 0) = -1 EINVAL (Invalid argument)
>
> This can probably be triggered in other ways given that coreutils often
> uses SSIZE_MAX as size argument[1][2]
>
> [1] https://cgit.git.savannah.gnu.org/cgit/coreutils.git/tree/src/cat.c?h=v9.9#n505
> [2] https://cgit.git.savannah.gnu.org/cgit/coreutils.git/tree/src/copy-file-data.c?h=v9.9#n130
> ---

I've found a simple shell reproducer, it might be worth adding it to
the commit message if the patch is considered for apply:

$ truncate -s $((2**63 - 1)) hugefile
$ dd if=hugefile bs=1M skip=$((2**43 - 2))
dd: error reading 'hugefile': Invalid argument
1+0 records in
1+0 records out
1048576 bytes (1,0 MB, 1,0 MiB) copied, 0,103536 s, 10,1 MB/s

Thanks,
-- 
Matteo Croce

perl -e 'for($t=0;;$t++){print chr($t*($t>>8|$t>>13)&255)}' |aplay

Il giorno sab 20 dic 2025 alle ore 13:45 Matteo Croce
<technoboy85@gmail.com> ha scritto:
>
> Il giorno ven 19 dic 2025 alle ore 13:53 Matteo Croce
> <technoboy85@gmail.com> ha scritto:
> >
> > The overflow check in rw_verify_area() can itself overflow when
> > pos + count > LLONG_MAX, causing the sum to wrap to a negative value
> > and incorrectly return -EINVAL.
> >
> > This can be reproduced easily by creating a 20 MB file and reading it
> > via splice() and a size of 0x7FFFFFFFFF000000. The syscall fails
> > when the file pos reaches 16 MB.
> >
> > splice(3, NULL, 6, NULL, 9223372036837998592, 0) = 262144
> > splice(3, NULL, 6, NULL, 9223372036837998592, 0) = 262144
> > splice(3, NULL, 6, NULL, 9223372036837998592, 0) = -1 EINVAL (Invalid argument)
> >
> > This can probably be triggered in other ways given that coreutils often
> > uses SSIZE_MAX as size argument[1][2]
> >
> > [1] https://cgit.git.savannah.gnu.org/cgit/coreutils.git/tree/src/cat.c?h=v9.9#n505
> > [2] https://cgit.git.savannah.gnu.org/cgit/coreutils.git/tree/src/copy-file-data.c?h=v9.9#n130
> > ---
>
> I've found a simple shell reproducer, it might be worth adding it to
> the commit message if the patch is considered for apply:
>
> $ truncate -s $((2**63 - 1)) hugefile
> $ dd if=hugefile bs=1M skip=$((2**43 - 2))
> dd: error reading 'hugefile': Invalid argument
> 1+0 records in
> 1+0 records out
> 1048576 bytes (1,0 MB, 1,0 MiB) copied, 0,103536 s, 10,1 MB/s
>
> Thanks,
> --
> Matteo Croce
>
> perl -e 'for($t=0;;$t++){print chr($t*($t>>8|$t>>13)&255)}' |aplay

Following a discussion on the coreutils mailing list[1] I think that
this should be fixed differently.
I'll be back with a v2.

[1] https://lists.gnu.org/archive/html/coreutils/2025-12/msg00097.html

Regards,
-- 
Matteo Croce

perl -e 'for($t=0;;$t++){print chr($t*($t>>8|$t>>13)&255)}' |aplay

> Following a discussion on the coreutils mailing list[1] I think that
> this should be fixed differently.
> I'll be back with a v2.

Ok.

On Fri, 19 Dec 2025 13:52:50 +0100, Matteo Croce wrote:
> The overflow check in rw_verify_area() can itself overflow when
> pos + count > LLONG_MAX, causing the sum to wrap to a negative value
> and incorrectly return -EINVAL.
> 
> This can be reproduced easily by creating a 20 MB file and reading it
> via splice() and a size of 0x7FFFFFFFFF000000. The syscall fails
> when the file pos reaches 16 MB.
> 
> [...]

Applied to the vfs.fixes branch of the vfs/vfs.git tree.
Patches in the vfs.fixes branch should appear in linux-next soon.

Please report any outstanding bugs that were missed during review in a
new review to the original patch series allowing us to drop it.

It's encouraged to provide Acked-bys and Reviewed-bys even though the
patch has now been applied. If possible patch trailers will be updated.

Note that commit hashes shown below are subject to change due to rebase,
trailer updates or similar. If in doubt, please check the listed branch.

tree:   https://git.kernel.org/pub/scm/linux/kernel/git/vfs/vfs.git
branch: vfs.fixes

[1/1] fs: fix overflow check in rw_verify_area()
      https://git.kernel.org/vfs/vfs/c/d77e4d49e5f0