Il giorno mar 23 dic 2025 alle ore 20:40 Paul Eggert
<[email protected]> ha scritto:
>
> On 2025-12-22 17:28, Matteo Croce wrote:
>
> > Where in cat.c the code avoids the overflow? I see:
> >
> > ssize_t copy_max = MIN (SSIZE_MAX, SIZE_MAX) >> 30 << 30;
> >
> > which should evaluate to 0x7FFFFFFFC0000000
>
> Oh, I might be mistaken here. I was looking at my experimental copy of
> coreutils, which has some changes/fixes in this area.
>
> > also strace says:
> >
> > $ strace -e copy_file_range cat /etc/fstab >fstab
> > copy_file_range(3, NULL, 1, NULL, 9223372035781033984, 0) = 568
> > copy_file_range(3, NULL, 1, NULL, 9223372035781033984, 0) = 0
> > +++ exited with 0 +++
>
> Those particular copy_file_range calls don't tickle the kernel bug, as
> the files are at offset 0. But you're right, you can probably tickle the
> kernel bug in other uses.
>
Maybe with a huge file and a seek, e.g.
$ truncate -s $((2**63-1)) file1
$ ( dd status=noxfer bs=1 skip=$((2**63-1)) count=0 && cat ) <file1 >file2
0+0 records in
0+0 records out
cat: -: Invalid argument
strace reveals:
copy_file_range(0, NULL, 1, NULL, 9223372035781033984, 0) = 0
read(0, 0xffff273fc000, 262144) = -1 EINVAL (Invalid argument)
I also see that copy_file_range() is used first and read().
I guess that it's because copy_file_range() returns 0,
so copy_cat() returns 'some_copied' which is 0,
which is propagated to 'copy_cat_status'
and then cat fallbacks to simple_cat()?
> > Yes, the kernel bug has to be fixed, of course.
> > Your patch doesn't compile due to an unmatched curly brace, I fixed it
> > but it panics at boot, can you check if I preserved the correct logic?
>
> No, but that's understandable as my patch was hopelessly munged. You can
> try the attached instead. (Notice that it does not fail with EOVERFLOW;
> either the requested area is valid or it's not.)
Will it as soon as I'll have my devel machine back.
Regards,
--
Matteo Croce
perl -e 'for($t=0;;$t++){print chr($t*($t>>8|$t>>13)&255)}' |aplay
