Bug#1115729: Stable fix request: error in internal cancellation syscall handling, corrupting copy_file_range syscall return value
Aurelien Jarno wrote on Sun, 16 Nov 2025 13:29 +00:00:
> On 2025-11-16 04:51, Daniel Shahaf wrote:
>> Joel Johnson wrote on Fri, Sep 19, 2025 at 08:45:10 -0600:
>> > Package: libc
>> > Version: 2.41-12
>> > Severity: grave
>> >
>> > (Marking as grave since it leads to data loss)
>> >
>> > An issue has been identified and fixed upstream causing data loss using
>> > copy_file_range. It is most prominent with OpenZFS but also appears to have
>> > potential impacts on FUSE. I would request that this be patched for a trixie
>> > update. I didn't see any existing issue for this, apologies if it's a
>> > duplicate.
>> >
>> > https://sourceware.org/git/?p=glibc.git;a=commitdiff;h=7107bebf19286f42dcb0a97581137a5893c16206
>> >
>> > https://sourceware.org/bugzilla/show_bug.cgi?id=33245
>> >
>> > https://debbugs.gnu.org/cgi/bugreport.cgi?bug=79139
>>
>> Morning. I haven't run into the buggy behaviour, but I did run into
>> this ticket in the apt-listchanges(1) output during an upgrade, and I'm
>> not sure whether the bug would impact me if I proceeded with the upgrade.
>>
>> Two questions:
>>
>> 1. Considering this bug is described as "data loss" and appears in
>> apt-listchanges(1) output for folks upgrading oldstable→stable, could
>> someone please summarize situations in which the bug is known /not/
>> to occur even under 2.41-12 (currently in trixie)?
>>
>> I'm not asking for an exhaustive list; just for common known-good
>> scenarios. Something of the form "It's safe to upgrade to trixie and
>> glibc/2.41-12 as long as you don't do X, Y, or Z" would be great.
>
> The bugs does not appear with usual filesystems like ext4 or xfs.
>
So, to be absolutely, 100% clear: it's not merely that the bug /has not
been observed/ under ext4 or xfs; the bug /will not/ happen for ext4 and xfs.
Thanks a lot. This unblocks upgrading for me.
>> 2. The bug is fixed in 2.41-2 in experimental, but hasn't yet been fixed
>
> Actually in 2.42-2.
>
Oops, yes.
>> in either sid or trixie (as requested by the OP). Is the bug
>> expected to be fixed in trixie?
>
> Yes, this is planned, but it has to be fixed before being able to fix
> it in trixie.
Glad to hear this. I realize that bugs have to be fixed in sid before
being fixed in stable.
>> I'm not sure what blocks 2.42 from being uploaded to sid.
>
> The plan was indeed to stop the maintenance of 2.41 in sid and upload
> 2.42 to sid. A lot of effort has been put on preparing 2.42, including
> an archive rebuild.
*nod* I see.
> Unfortunately this is currently blocked by #1115881
> with no answer from the Ada maintainers...
>
> After that I lost all my motivation to work on glibc. I guess, I'll try
> to upload a new 2.41 version to sid, so that we can fix the bug in
> trixie...
I'm afraid I haven't got anything to contribute to the gnat-XXX provides
question, or to why -ada@ haven't replied (perhaps a follow-up to -ada@
would help?), but for whatever it may be worth, I for one would very
much appreciate cherry-pick uploads into sid and stable-proposed-updates:
I'd rather not be running a production system on a locally-patched libc,
nor with a "no fly zone" around use of certain filesystems.
(I mean, if I were to upgrade and implement a "don't use anything but
ext4 and xfs for the time being" policy, I'd want to take the precaution
of preventing creation and mounting of other types of filesystems, and
I'm not sure how I'd do that… dpkg-divert(8)ing mkfs(8) and writing a
wrapper around it wouldn't be sufficient, would it?)
>> I've verified the patch above (7107bebf19286f42dcb0a97581137a5893c16206)
>> applies cleanly to the version in trixie. I've tried to build it,
>> too; the build didn't actually pass, but at least it failed in the
>> same way with the patch and without it, and the failure may well be
>> unrelated to the patch. (I was building in a new trixie chroot.)
>
> Yes, this is likely unrelated, and probably depends on the way your
> chroot is setup. The best is to use the unshare feature of sbuild which
> provide a reproducible environment. You have to look at the output file
> of the individual errors (which should be dumped earlier in the build
> log) to understand the issue.
>
Thanks for the pointers.
This was in a pbuilder chroot on a bookworm host, with default settings
(no .pbuilderrc exists). I'm afraid I didn't keep the build log.
Next time around I'll give sbuild+unshare a spin, or possibly build in a
new VM.
Thank you for the very quick reply,
Daniel
> Regards
> Aurelien
Reply to: