Today I have spent way too much time handling the https://copy.fail situation #copyfail
-
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
-
@noisytoot @alexanderkjall it's not like you'll be running the exploit on some microcontroller with 16K of SRAM
@fun @noisytoot @alexanderkjall the reason is marketing, not technical
"we are so good because we need very few bytes to achieve this massive thing"
-
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@mastodon.social They even have time to obfuscate and minimize that exploit code, which makes it very hard to understand.
As if "732 bytes" means anything.
Surely the best way to create a proof-of-concept exploit to share their understanding with the world? /s -
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 I mean... it is normal that, as a security researcher, when you find a security bug, you contact the upstream vendor, and can expect that to result in the issue being handled appropriately (for example, because the project notifies their downstreams about the issue, or because downstreams generally pick up all patches fast, or because propagation of fixes is ensured through a mechanism like CVEs).
To my knowledge, there is no such mechanism between Linux and most distros, unless the distro just always ships the latest stable kernel; I think that is a process issue, not the security researcher's fault.
When I report Linux kernel security bugs, I, too, just send the bug report to security@kernel.org and the maintainers, not to the third-party linux-distros list.
-
@alexanderkjall @jmm hmm…
> As such, the kernel security team strongly recommends that as a reporter of a potential security issue you DO NOT contact the “linux-distros” mailing list UNTIL a fix is accepted by the affected code’s maintainers and you have read the distros wiki page above and you fully understand the requirements that contacting “linux-distros” will impose on you and the kernel community.Well, if it’s too complicated to be a reporter, there is always fulldisclosure@seclists.org.
@LabanSkoller @alexanderkjall @jmm You don't get the props for that that you used to. Giving it a cute name and marketing campaign is the thing these days.
-
@alexanderkjall But they say they 'Reported to Linux kernel security team' on 23rd March; shouldn't that have triggered the distros finding out?
@penguin42 @alexanderkjall No. That situation is really complicated and easy to fuck up.
-
@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.
@penguin42 @fedops @alexanderkjall That's also on NIST, and the aren't doing too well right now.
-
@alexanderkjall And there I sat, thinking it was just me being too dumb to figure out whether I had a patched kernel without running their bespoke, obfuscated script.
@OmegaPolice @alexanderkjall It is /not/ just you.
-
@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 @fun @alexanderkjall I was wondering about that (haven't had to deal with actual Redhat since 2013)...
-
@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 @noisytoot @alexanderkjall It totally is.
-
@alexanderkjall@mastodon.social They even have time to obfuscate and minimize that exploit code, which makes it very hard to understand.
As if "732 bytes" means anything.
Surely the best way to create a proof-of-concept exploit to share their understanding with the world? /s@Orca @alexanderkjall Not anymore.
-
@noisytoot @alexanderkjall it's just not serious
@fun @noisytoot @alexanderkjall It is not serious, but OTOH the exploit is simple enough that it's still relatively easy to decipher.
-
@alexanderkjall Brad Spender (GRSecurity) has been highly critical of the Linux Kernel security bug handling process since forever, and one of those criticisms is that the members of security@kernel.org don't notify the linux-distros security list, or really triage severity in a way that he approves of as a security vendor and practitioner, their "security bugs are just bugs" stance that refuses to give priority to security issues is infuriating to some people who see security bugs as higher priority than any other kind of bug.
@raven667 @alexanderkjall Isn't the stance rather that all bugs are security bugs?
I mean it doesn't change much in practice, but it's a better argument IMO.
-
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 you can't expect that guy to notify everybody. He notified the kernel security list, but they didn't communicate downstream.
-
@fun @noisytoot @alexanderkjall the reason is marketing, not technical
"we are so good because we need very few bytes to achieve this massive thing"
@eloy @noisytoot @alexanderkjall The only reason I can think of to use this for marketing is .. yeah, what you said, and maybe also "hey our AI is so good!!!"
