Today I have spent way too much time handling the https://copy.fail situation #copyfail
-
@penguin42 yeah I understand the back ports problem but there was a patch in mainlinel. The timeline says:
2026-03-25 Patches proposed and reviewed
2026-04-01 Patch committed to mainlineSurely "proposed and reviewed" must have caught someone's interest?
The sad thing is a patch wasn't even necessary. Disabling the ALG function via bootparam was completely enough except in rare cases where crypto performance actually counts.
@fedops @alexanderkjall To me it seems the delay in registering the CVE was the big problem here; if the CVE was registered, the distro people would have at least something to track (even if no one had mailed the distro list). Still it feels like each of the 3 components should be mailing the other.
-
@fedops @penguin42 I'm not part of any distro security team, so I can't really speak for any of them.
But Debian contains about 40000 source packages as of may 2026, it feels slightly unrealistic that the security team are supposed to track patches for all of those and understand which ones contain important security fixes.
If you find a vulnerability, register a website and build an exploit, then notifying the vendors beforehand feels like a quite small thing in comparison.
@alexanderkjall I agree and to be clear I have very low respect for that security outfit (and most others as well). Disclosure: I work in industrial cybersec.
However, arguably monitoring the kernel security is the most important thing. If you have a security team in your distro crew and they're not taking a keen interest in kernel security, what are they really doing?
That being said a simple email to the 15 or so distros that matter would not have been too big an ask.
@penguin42 -
Today I have spent way too much time handling the https://copy.fail situation #copyfail
The persons who discovered it didn't notify the distribution security list, so no patched kernels was available for people to install when they released it.
But they did have time to write an exploit, and thought it was a good idea to distribute that on day one, before vendors had time to provide patches.
I'm not very impressed with xint.io, I guess it's the marketing department that runs the show.
Will Dormann (@wdormann@infosec.exchange)
What went wrong with this case? Theori appear to have only contacted the linux kernel devs with the vulnerability, as opposed to going the usual CVD route that includes all of the major Linux distros. Why is this a problem? Since the linux kernel became a CNA, there has been a [flood of CVEs for the Linux kernel](https://tuxcare.com/blog/the-linux-kernel-cve-flood-continues-unabated-in-2025/). The Linux kernel devs' arguments is that any given kernel flaw could presumably be leveraged to behave as a vulnerability, and it's not worth their time to determine "vulnerability" or "not a vulnerability". Everything gets a CVE. Now the case with copy.fail? It was indeed reported to the kernel devs. And it got a CVE. A single CVE buried in flood of all of the Linux kernel CVEs. And it appears that every distro on the planet was blindsided by this proven-exploitable vulnerability because they were not given any warning. Or even any suggestion to pick this single CVE out of the sea of Linux kernel CVEs as worth cherry picking. Much to the chagrin of the Linux devs, RHEL doesn't use up-to-date Linux kernels. They cherry pick CVEs to backport to their chosen kernel version. (e.g. the latest and greates RHEL 10.1 uses 6.12.0, which was released November 17 2024). And in this world where bad actors like Theori don't involve vendors in vulnerability coordination, and just about every Linux kernel bug gets a CVE, this workflow fails. Hard. Good times...
Infosec Exchange (infosec.exchange)
-
@alexanderkjall I agree and to be clear I have very low respect for that security outfit (and most others as well). Disclosure: I work in industrial cybersec.
However, arguably monitoring the kernel security is the most important thing. If you have a security team in your distro crew and they're not taking a keen interest in kernel security, what are they really doing?
That being said a simple email to the 15 or so distros that matter would not have been too big an ask.
@penguin42 -
@alexanderkjall @penguin42 fwiw I agree with gkh:
https://social.kernel.org/objects/e5b49e64-befb-43a8-aab3-33c7f3705a99@fedops @alexanderkjall Oh, that says no one contacted the security team - which contradicts what it said in the blog of the guys who found it.
-
@fedops @alexanderkjall Oh, that says no one contacted the security team - which contradicts what it said in the blog of the guys who found it.
@penguin42 well he says "they told us", which means the kernel team.
@alexanderkjall -
@penguin42 well he says "they told us", which means the kernel team.
@alexanderkjall@fedops @alexanderkjall Oh OK, I see, yeh they told them about the bug, but didn't tell them about the announcement. Yeh, that sucks.
-
Today I have spent way too much time handling the https://copy.fail situation #copyfail
The persons who discovered it didn't notify the distribution security list, so no patched kernels was available for people to install when they released it.
But they did have time to write an exploit, and thought it was a good idea to distribute that on day one, before vendors had time to provide patches.
I'm not very impressed with xint.io, I guess it's the marketing department that runs the show.
@alexanderkjall "The persons who discovered it didn't notify the distribution security list, so no patched kernels was available for people to install when they released it."
Sorry, but it is not the persons responsibility to look out whom to contact.
As per the linked page, he reported to Linux kernel security team on May 23nd.In my opinion it is responsibility of distributions to be in the loop of kernel security team.
-
@alexanderkjall "The persons who discovered it didn't notify the distribution security list, so no patched kernels was available for people to install when they released it."
Sorry, but it is not the persons responsibility to look out whom to contact.
As per the linked page, he reported to Linux kernel security team on May 23nd.In my opinion it is responsibility of distributions to be in the loop of kernel security team.
@asltf Since the kernel have the policy "every bug gets a CVE" ( https://docs.kernel.org/process/cve.html ), that seems like a full time job for multiple people.
They published 200 CVE's since 2026-04-24: https://lore.kernel.org/linux-cve-announce/topics_new.html
I guess the security team of your favorite linux distribution would appreciate some support.
-
That's not what the disclosure timeline claims:
2026-03-23 Reported to Linux kernel security team
2026-03-24 Initial acknowledgment
2026-03-25 Patches proposed and reviewed
2026-04-01 Patch committed to mainline
2026-04-22 CVE-2026-31431 assigned
2026-04-29 Public disclosure (https://copy.fail/)Is this timeline in error?
@simonzerafa @alexanderkjall Disclosure to Linux, but not to the distros.
-
That's not what the disclosure timeline claims:
2026-03-23 Reported to Linux kernel security team
2026-03-24 Initial acknowledgment
2026-03-25 Patches proposed and reviewed
2026-04-01 Patch committed to mainline
2026-04-22 CVE-2026-31431 assigned
2026-04-29 Public disclosure (https://copy.fail/)Is this timeline in error?
@simonzerafa @alexanderkjall How do distros know that there is a vulnerability in the wild? -
Today I have spent way too much time handling the https://copy.fail situation #copyfail
The persons who discovered it didn't notify the distribution security list, so no patched kernels was available for people to install when they released it.
But they did have time to write an exploit, and thought it was a good idea to distribute that on day one, before vendors had time to provide patches.
I'm not very impressed with xint.io, I guess it's the marketing department that runs the show.
@alexanderkjall they also had time to obfuscate their exploit. -
Today I have spent way too much time handling the https://copy.fail situation #copyfail
The persons who discovered it didn't notify the distribution security list, so no patched kernels was available for people to install when they released it.
But they did have time to write an exploit, and thought it was a good idea to distribute that on day one, before vendors had time to provide patches.
I'm not very impressed with xint.io, I guess it's the marketing department that runs the show.
@alexanderkjall let's say how it is Greg didn't put it into backports and no one could be arsed to look at it by themselfes as it is, in deed, work.
Maybe get mad at Herbert (who commited the kernel fix patch) for not telling the distribution security list?
Anyways, the result is a massive PR event for Xinit/theori and a bad day for Distro security teams and IT Security people all over the world (oh well at least most of you should be geting payed a nice premium for working at May 1st).
I guess learning from it would be better then finger pointing but who am I to tell you all how to do your jobs?
I'm retired. My local machines with public services sit fully proxied behind a BSD machine. The only person with shell access (from my LAN only) is me.
If the Hyperscaler guys don't pay people to monitor CVEs and do their own classification well
️
️ -
@alexanderkjall they also had time to obfuscate their exploit.@fun @alexanderkjall It's minified rather than obfuscated, I think they did that just so they could say it was only 732 bytes.
It's also likely that they just asked an LLM to minify it, given that the whole article was so obviously AI-generated and not even proofread (it originally claimed to have been tested on RHEL 14.3, which does not exist) -
That's not what the disclosure timeline claims:
2026-03-23 Reported to Linux kernel security team
2026-03-24 Initial acknowledgment
2026-03-25 Patches proposed and reviewed
2026-04-01 Patch committed to mainline
2026-04-22 CVE-2026-31431 assigned
2026-04-29 Public disclosure (https://copy.fail/)Is this timeline in error?
@simonzerafa @alexanderkjall the Linux kernel security team did not tell distros -
@fun @alexanderkjall It's minified rather than obfuscated, I think they did that just so they could say it was only 732 bytes.
It's also likely that they just asked an LLM to minify it, given that the whole article was so obviously AI-generated and not even proofread (it originally claimed to have been tested on RHEL 14.3, which does not exist)@noisytoot @alexanderkjall it's also obfuscated IMO. Why need to zlib.decompress ? Can't you give us the data itself without compression?
A bunch of variables also have quite meaningless names. It really does scream a lot like obfuscation. -
@alexanderkjall I read that they had waited a month with distributing the PoC and that major distributions were prepared.
@LabanSkoller @alexanderkjall they waited a month after reporting to the Linux kernel security team, they did not report to distros
Debian at least was quite clearly unprepared given that it took a day to get fixed in trixie and only just got fixed in bookworm (between when I last checked earlier today and now) -
@noisytoot @alexanderkjall it's also obfuscated IMO. Why need to zlib.decompress ? Can't you give us the data itself without compression?
A bunch of variables also have quite meaningless names. It really does scream a lot like obfuscation.@fun @alexanderkjall both of those are for minification: if it used descriptive variable names and didn't compress the payload it would have been longer than 732 bytes -
@fun @alexanderkjall both of those are for minification: if it used descriptive variable names and didn't compress the payload it would have been longer than 732 bytes@noisytoot @alexanderkjall it's just not serious
-
@noisytoot @alexanderkjall it's just not serious@noisytoot @alexanderkjall it's not like you'll be running the exploit on some microcontroller with 16K of SRAM
