So CopyFail CVE-2026-31431 is a thing.
-
@penguin42 @deftpunk @joshbressers @wdormann @Viss I honestly don't remember, and if I did, we don't publish who asked for CVE ids from us as that's generally not a good idea to do so (and is not a requirement for being a CNA).
@gregkh @deftpunk @joshbressers @wdormann @Viss Hmm OK - tbh I think that gap to the CVE being issued is the biggest thing here (says he on the outside), if that was issued earlier I think there would have been a better chance a distro might have noticed. So perhaps if linux-security makes sure it reminds reporters to do it, and also asks them to give you a heads up before any announcement that might have helped here.
-
@joshbressers @wdormann @deftpunk @Viss What do you mean, they told us, we fixed it, it got in some stable kernels, and so our work on the security team was done. The CVE team assigned a CVE after a while, and even gave it a CVSS score.
The fact that no distro popped up that used older kernel versions to do the real work to backport to older kernels seems to be everyone's major problem here. That is outside of the kernel security team's work entirely. So take it up with the distros that people are paying support for to do this for them?
And yes, Debian was vulnerable, that is not good, and once it was noticed people worked hard and quickly to fix that. Not bad for a community-based distro that no one pays for in my opinion.@gregkh @deftpunk @joshbressers @wdormann @Viss I think we (the distro security teams, speaking as a member of the Debian one) would have liked a heads up, including maybe to help backporting to the stable kernel we run. We didn't have that heads up, we discovered the thing like everyone else.
-
@gregkh @deftpunk @joshbressers @wdormann @Viss I think we (the distro security teams, speaking as a member of the Debian one) would have liked a heads up, including maybe to help backporting to the stable kernel we run. We didn't have that heads up, we discovered the thing like everyone else.
@gregkh @deftpunk @joshbressers @wdormann @Viss
As Greg mentioned, vulnerability coordination is difficult, and it's hard to draw a line about who to include and who not to.
Maybe the researchers thought they did the right thing by notifying the kernel security team (and they did), and they thought it was enough. But I don't think it's written anywhere that the kernel security team will coordinate with downstream (or anyone else), and again I'm not sure it's really possible.
-
@gregkh @deftpunk @joshbressers @wdormann @Viss
As Greg mentioned, vulnerability coordination is difficult, and it's hard to draw a line about who to include and who not to.
Maybe the researchers thought they did the right thing by notifying the kernel security team (and they did), and they thought it was enough. But I don't think it's written anywhere that the kernel security team will coordinate with downstream (or anyone else), and again I'm not sure it's really possible.
@gregkh @deftpunk @joshbressers @wdormann @Viss
Still, it leaves a bit of a bitter taste. Not sure how we can do better though. -
@wdormann @joshbressers @Viss I love it how people think that "coordination of vulnerabilities" is actually something that can be done these days. Think of just who uses the software in question, and who should, and should not, be on such a list to get a "early disclosure notification".
As I have said for quite some time now, all early-disclosure lists are leaks, otherwise why would your government allow them to be in existence?
Software, and specifically open source software, runs the world. So should the whole world be on that notification list?
@gregkh @joshbressers @wdormann @Viss so there's absolutely no middle ground? When there is clearly a bug with security impact, give the distros list a week notice (two weeks max, per their policy). If it leaks, outcome is no worse than not notifying distros. The researcher can even do it instead of the kernel. At scale (Linux!) this seems like a Pareto distribution: major distros cover disproportionally most users.
-
@gregkh @deftpunk @joshbressers @wdormann @Viss
Still, it leaves a bit of a bitter taste. Not sure how we can do better though.@corsac
> Not sure how we can do better thoughA random idea, not sure how far it is from what you already do:
Bump automation where packages from latest stable branches are built and available with no human intervention in specific repositories. Manual promotion for generic repos should be as effortless as possible. -
@corsac
> Not sure how we can do better thoughA random idea, not sure how far it is from what you already do:
Bump automation where packages from latest stable branches are built and available with no human intervention in specific repositories. Manual promotion for generic repos should be as effortless as possible.@Aissen The process is already pretty scripted but there's still some manual things to do (whether in the kernel packaging or in the DSA processing).
On Apr 30th v6.12.85 was tagged at 1116Z and the DSA was sent at 2005Z. I'm unsure we can do much faster.
note: I didn't do anything this time, it's mainly the work of Salvatore Bonaccorso (as a volunteer): https://salsa.debian.org/kernel-team/linux/-/merge_requests/1895
-
@letoams @CliffsEsport
Up-to-date Fedora (42 or later) are not affected at the time of publication (Yesterday).
At least on this Fedora 42 system, the kernel was built on April 23 and in stable 2 days ago. Not a few hours ago.@wdormann weird because I had a successful test on up to date f42 yesterday …
-
@wdormann weird because I had a successful test on up to date f42 yesterday …
@letoams
Got a snapshot that you can revert to?
I'd like to see the evidence (along with showing the current kernel version). -
@gregkh @joshbressers @wdormann @Viss so there's absolutely no middle ground? When there is clearly a bug with security impact, give the distros list a week notice (two weeks max, per their policy). If it leaks, outcome is no worse than not notifying distros. The researcher can even do it instead of the kernel. At scale (Linux!) this seems like a Pareto distribution: major distros cover disproportionally most users.
@zmanion @joshbressers @wdormann @Viss Why is linux-distros somehow "special" enough to get these types of announcements and not everyone else? How exactly would you explain that to your favorite government entity? -
@letoams
Got a snapshot that you can revert to?
I'd like to see the evidence (along with showing the current kernel version).@wdormann it seemed my VM was on 6.18.7–100 and hadn’t pulled in the updates yet
-
There's also a C version of it that works quite well. Even supports aarch64.
The CEO of Theori / Xint has a damage-control thread explaining why they chose to release the vulnerability details in a way that left all of the Linux distros in the dark.
TL;DR: With AI in the mix, the old way of coordinating vulnerabilities doesn't scale anymore.
-
@k8ie
Yes, it's clear that it was published as a "Look at us!" vehicle.But their abysmally bad coordination put every Linux user on the planet at risk, and is clear evidence that they don't care about anybody other than themselves.
@wdormann @k8ie From what I've seen having been volunteered to be our infosec d00d, quarterbacking a coordination of affected downstream parties can sometimes be a big PITA. But no familiarity with the linux kernel CVD process - I presume its not as onerous as these guys are claiming?
Like.. isn't there a dist.list/channel that all distro maintainers hang out on? call a meeting, answer questions, set a timetable, take minutes... pain yes but not that hard..?
-
The CEO of Theori / Xint has a damage-control thread explaining why they chose to release the vulnerability details in a way that left all of the Linux distros in the dark.
TL;DR: With AI in the mix, the old way of coordinating vulnerabilities doesn't scale anymore.
@wdormann TL;DR: lame AI excuse award for laziness and incompetence
-
@wdormann TL;DR: lame AI excuse award for laziness and incompetence
@ReneRebe
Yeah.I mean, fine, you can say that Qualys is doing it this way too. But TBH, I got the impression that the Qualys example was found after the fact when everything blew up, as opposed to purposefully modeling your workflow after Qualys.
But the real red flag is this:
Patch first. Update your distribution's kernel package to one that includes mainline commit a664bf3d603d — it reverts the 2017 algif_aead in-place optimization, so page-cache pages can no longer end up in the writable destination scatterlist. Most major distributions are shipping the fix now.No human being on the planet would have concluded such a thing. Anyone with half a wit would know for a fact that no distribution had updates at the time that copy.fail was published. Not even one of the FOUR DEMO DISTROS IN THE PAGE ITSELF.
️This all was AI-driven YOLO attention seeking, and the linked thread from Brian is just damage control.
-
The CEO of Theori / Xint has a damage-control thread explaining why they chose to release the vulnerability details in a way that left all of the Linux distros in the dark.
TL;DR: With AI in the mix, the old way of coordinating vulnerabilities doesn't scale anymore.
@wdormann Hi Will. Shouldn't/couldn't the Linux security team have imposed an embargo and coordinated with the distro's?
-
@wdormann Hi Will. Shouldn't/couldn't the Linux security team have imposed an embargo and coordinated with the distro's?
@aristot73
In an ideal world, yes.
But they're not interested in doing such things.
For reasons, presumably.
-
@aristot73
In an ideal world, yes.
But they're not interested in doing such things.
For reasons, presumably.@wdormann wow....
️ -
While this vulnerability seems to be discovered using AI ("Xint Code"), I have to assume that they also let the AI decide how to do the vulnerability coordination as well.
major builds are out as of this writing
No distros have official updates for CVE-2026-31431. Fedora 42 and newer have updates, but no official advisory or acknowledgement of CVE-2026-31431. So with them it's unclear if it's even intentional. Red Hat, Ubuntu, Amazon Linux, and Suse all have advisories as of now, but NO updates.disable the algif_aead moduleas a mitigation.
Bespoke distros like RHEL don't use a module, it's compiled into the kernel.
I can't figure out what the Xint Code angle is with this copyfail stuff. On one hand, yes, it is a true vulnerability that affects a LOT of Linux distros available. And they did submit the bug for fixing to the upstream kernel people.
BUT the CVE has only existed for a week. And NONE of the distros IN THEIR ADVISORY had updates available at the time that they pulled the trigger for publication of the shiny copy.fail website.
I struggle to think of how this even happens. In all my years of infosec, you're either on board with doing CVD (e.g. coordinating with the former CERT/CC) or you're not (dropping 0day). But this all fits bizarrely in the middle. The publication gives the guise that they did the right thing, (and please use our AI services). But at the same time, they clearly chose to release the vulnerability details and functional exploit before any distro had the ability to properly do anything about it.
Either these Xint Code (Theori) people have a hidden agenda or ulterior motive that we aren't aware of yet. Or they're just really bad at coordinated vulnerability disclosure. You pick.
@wdormann What really shit me off about the thing is the PoC test code they published.
They suggest you run it by curl'ing a URL from their site, directly into python and su.
On a vulnerability that's a fastpath to root.
But it gets better because you look at the code and it's obfuscated? No comments, no detail, compacted as much as possible for python.Okay, it's fairly basic obfuscation, I could work it out in a few minutes.
It runs an x86_64 ELF binary, that it ships as hex-encoded zlib.
-
@wdormann What really shit me off about the thing is the PoC test code they published.
They suggest you run it by curl'ing a URL from their site, directly into python and su.
On a vulnerability that's a fastpath to root.
But it gets better because you look at the code and it's obfuscated? No comments, no detail, compacted as much as possible for python.Okay, it's fairly basic obfuscation, I could work it out in a few minutes.
It runs an x86_64 ELF binary, that it ships as hex-encoded zlib.
@wdormann Just incase I need to say this for anyone, and I'm really hoping I don't.
I've never seen a worse PoC code. You are supposed to ship extremely readable, well documented code that demonstrates procedure of the exploit.
You do not suggest people fucking blindly run it from a URL directly onto a machine, without any visibility into what's even running???
I've never heard of a quicker way of getting your machines shoved into a botnet.
