Bug 33245 - nptl: error in internal cancellation syscall handling, corrupting copy_file_range syscall return value
Summary: nptl: error in internal cancellation syscall handling, corrupting copy_file_r...
Status: RESOLVED FIXED
Alias: None
Product: glibc
Classification: Unclassified
Component: nptl (show other bugs)
Version: 2.41
: P2 normal
Target Milestone: 2.43
Assignee: Not yet assigned to anyone
URL: https://debbugs.gnu.org/cgi/bugreport...
Keywords:
Depends on:
Blocks:
 
Reported: 2025-08-01 17:59 UTC by Adhemerval Zanella
Modified: 2025-11-13 09:28 UTC (History)
4 users (show)

See Also:
Host:
Target:
Build:
Last reconfirmed:
Project(s) to access:
ssh public key:

Attachments
Add an attachment (proposed patch, testcase, etc.)

Note You need to log in before you can comment on or make changes to this bug.
Description Adhemerval Zanella 2025-08-01 17:59:00 UTC 
The SYSCALL_CANCEL calls __syscall_cancel, which in turn __internal_syscall_cancel with an 'int' argument instead of the expecting 'long int'. I might cause issues on syscalls that might return values larger than INT_MAX, such as copy_file_range [1].

[1] https://debbugs.gnu.org/cgi/bugreport.cgi?bug=79139
Comment 1 Adhemerval Zanella 2025-08-01 19:59:19 UTC 
Fixed on 2.43.
Comment 2 Sam James 2025-08-02 12:17:09 UTC 
Florian's posted a test: https://inbox.sourceware.org/libc-alpha/lhuy0s2eyrr.fsf@oldenburg.str.redhat.com/ (thanks)

(In reply to Adhemerval Zanella from comment #0)
> such as copy_file_range [1].

I don't know if we need to cover sendfile? https://inbox.sourceware.org/libc-alpha/87zfciypir.fsf@gentoo.org/#t
Comment 3 Florian Weimer 2025-08-02 12:48:46 UTC 
(In reply to Sam James from comment #2)
> I don't know if we need to cover sendfile?
> https://inbox.sourceware.org/libc-alpha/87zfciypir.fsf@gentoo.org/#t

Good point, but sendfile is currently not cancellable. I don't know how it is represented in the FUSE protocol.
Comment 4 Sam James 2025-08-03 09:34:32 UTC 
FTR, backports done as:
* 7107bebf19286f42dcb0a97581137a5893c16206 (2.41)
* b38f3f60d5b157edcf4d8bd1fd3ed02d417889e0 (2.42)

(In reply to Sam James from comment #2)
> I don't know if we need to cover sendfile?
> https://inbox.sourceware.org/libc-alpha/87zfciypir.fsf@gentoo.org/#t

(Self-followed up at https://inbox.sourceware.org/libc-alpha/87a54hzgmp.fsf@gentoo.org/)
Comment 5 Sourceware Commits 2025-08-05 13:25:52 UTC 
The master branch has been updated by Florian Weimer <fw@sourceware.org>:

https://sourceware.org/git/gitweb.cgi?p=glibc.git;h=9a2aceb076b8aa6ffa8edb4adcc9f43a2d3a352d

commit 9a2aceb076b8aa6ffa8edb4adcc9f43a2d3a352d
Author: Florian Weimer <fweimer@redhat.com>
Date:   Sat Aug 2 12:44:51 2025 +0200

    Linux: Add test case for bug 33245
    
    The copy_file_range system call seems to be the only one that can
    return an off64_t value.  Use FUSE to exercise this, without actually
    creating such large files or copying any data.  Due to FUSE protocol
    limitations, only sizes up to UINT_MAX can be tested, but this is
    sufficient to check for the presence of bug 33245.
    
    The FUSE protocol limitations are raised here:
    
      copy_file_range return value on FUSE
      <https://lore.kernel.org/all/lhuh5ynl8z5.fsf@oldenburg.str.redhat.com/>
    
    Reviewed-by: Sam James <sam@gentoo.org>
    Reviewed-by: Collin Funk <collin.funk1@gmail.com>
Comment 6 Sam James 2025-08-10 07:06:05 UTC 
(In reply to Sourceware Commits from comment #5)
>     The FUSE protocol limitations are raised here:
>     
>       copy_file_range return value on FUSE
>       <https://lore.kernel.org/all/lhuh5ynl8z5.fsf@oldenburg.str.redhat.com/>

-> https://marc.info/?l=fuse-devel&m=175441868526467&w=2