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 indeed

@alexanderkjall I read that they had waited a month with distributing the PoC and that major distributions were prepared.

@alexanderkjall

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?

@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)

@simonzerafa @alexanderkjall the Linux kernel security team did not tell distros

@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.

@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)

@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 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"

@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.

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.

@noisytoot @fun @alexanderkjall I was wondering about that (haven't had to deal with actual Redhat since 2013)...

@fun @noisytoot @alexanderkjall It totally is.

@fun @noisytoot @alexanderkjall It is not serious, but OTOH the exploit is simple enough that it's still relatively easy to decipher.

@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!!!"

@eloy @alexanderkjall @noisytoot but oh boy the coding style is much worse than literal amlogic kernel BSP

@alexanderkjall But they say they 'Reported to Linux kernel security team' on 23rd March; shouldn't that have triggered the distros finding out?

@penguin42 It did not, the process is somewhat described here: https://docs.kernel.org/process/security-bugs.html

@alexanderkjall That feels too complicated to leave to leave just to a (potentially 1st time) reporter. I would have hoped that at the very least the LK security team would track with the reporter and remind them of the need to do the other bits regularly. Especially on a nasty one!

@penguin42 I place some amount of blame with distro maintainers for not following up on patches released by the kernel team. I know it's not a thankful job, but it needs to be done.

@alexanderkjall

@fedops @alexanderkjall In this case it doesn't seem to have been that simple; The backports to older kernels were only released upstream yesterday, and the CVE only got assigned a week or two back; so it's not clear if anyone new. I'd love to know if the kernel security guys told anyone there were some pending.

@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 mainline

Surely "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.

@alexanderkjall

@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

@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.

@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.

@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.

@alexanderkjall ditto on spending too much time, & agreed they should have notified distro maintainers 😑

@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 Sounds like reasonable criticism to me. But then, an extended group of volunteers can only be expected to do so much. If we want SLAs, we have to pay people.

@alexanderkjall

An "AI-assisted finding", using a pretty AI-written and designed looking website, m-dash, semicolons, it has it all 🤔
Couldn't their AI also tell them how to report it properly???

@OmegaPolice @alexanderkjall yes and the majority of Linux kernel development is not volunteers, its a consortium of vendors organized through the Linux Foundation trade org which _does_ pay people. There are still volunteers who work on Linux but they shouldn't be a shield for the majority to pretend they are "just a smol bean, uwu" and dont have some responsibilities.

I'm the *first* to say that dragging volunteer FOSS maintainers is shitty (and that volunteers shouldn't cosplay as commercial vendors, by doing things like having public issue trackers, as it is nonsense to "open a support case" with a tracking number against a *volunteer*) but Linux kernel has volunteers it is not a volunteer led project anymore, its a consortium of major companies which benefit from pooling effort and having a neutral forum to collaborate.

I think security focused people, whose customers are also prioritizing security sometimes dont have empathy for or understand people who don't have security as their top priority, and treat people who don't share their priorities as stupid and incompetent, rather than understanding the differences in goals and constraints. That said there is probably room for improvement on kernel security, but more from a better systematic approach to prevent defects than treating every bug with a website as some super secret special thing. the current design makes a constant stream of local exploits inevitable

@raven667 @OmegaPolice I agree that it would be great if the kernel security team had a process that made life simpler for downstream vendors.

But since neither me or my employer contributes anything to make that happen I don't think it's my place to have public opinions about it.

Personally I would love to see more effort focused on reducing the attack surface of the kernel.

@simonzerafa @alexanderkjall Disclosure to Linux, but not to the distros.

@LabanSkoller @alexanderkjall if they say so, they are lying. The distros security list wasn't notified and there was no headsup to Debian outside of the list either. And Ubuntu surely neither, otherwise they wouldn't have just pushed a patched kmod package with the module blacklisted...

@jmm @alexanderkjall I think I mixed it up with the Linux kernel security team. But shouldn’t *that* team notify the distros?

@LabanSkoller @jmm They do not, the process is somewhat described here: https://docs.kernel.org/process/security-bugs.html

@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 @jmm @alexanderkjall No non I actually read that too from the FAQ on the Copyfail page yesterday. So. That was a lie?

@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 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 🤦🏿‍♀️🤷🏿‍♀️

@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.

@alexanderkjall

https://infosec.exchange/@wdormann/116495106231293342

@penguin42 @alexanderkjall I agree, having to report to 3 different lists, in a particular order, all with their own policies and methods of working, seems overly complex.

(the complexity may be necessary, but I can see why someone might miss out some steps)

@alexanderkjall yeah they sure come across as an amateurish outfit with moves like this

@penguin42 @alexanderkjall No. That situation is really complicated and easy to fuck up.

@alexanderkjall and strangely disclosed just before the 1st of may, like the mongobleed disclosed just before 1st of January.
Almost as a buzz strategy, pushing IT folks to work on weekends and public holidays.
Seriously, waiting next Monday, letting a weekend to all distros was so hard?

@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.

@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.

@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.

@jmm @LabanSkoller @alexanderkjall yeah, it's definitely not been handled optimally. on the RH side, Fedora happens to be OK as the fix landed upstream in 6.19.12 and that already went stable, but RHEL (and hence CentOS and probably Alma and Rocky) are affected with no day-0 update - https://access.redhat.com/security/cve/cve-2026-31431 .

@alexanderkjall can't say I care, I'm just happy it was found atp

@Arcaik @alexanderkjall thats probably a better framing, and it points to the fundamental disagreement, security vendors see the kernel issuing thousands of CVEs as malicious compliance rather than an admission that _any_ of those bugs could have security implications, and they are all important, so none of them are _more_ important.

The security people are right about something too though, high profile bugs with websites and such are more likely in practice to be exploited because the likelihood is based on human choice or preference, not strictly technical possibility.

@drwho @penguin42 @fedops @alexanderkjall The kernel CVE assignment team has their own CNA, but their policy is to tag a CVE to everything that could potentially be a security problem, and they don't usually do scores, so kernel CVEs are nigh useless to track the criticality of security bugs, see https://lore.kernel.org/linux-cve-announce/

(In this particular case, the CVE had a score, which might have served as a signal for something unusual.)

The process around disclosure of kernel security problems has been completely dysfunctional for years, and every time something out of the ordinary happens, the same people turn up with the same conflicting viewpoints 🤷‍♂️

Greg KH has written about how the kernel security team handles things earlier this year: https://h.jort.link/www.kroah.com/log/blog/2026/01/02/linux-kernel-security-work/