So CopyFail CVE-2026-31431 is a thing.
-
@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.
-
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.
"From that prior experience, we assumed distros had ways to learn about upstream security-critical bugs. We never needed to notify them explicitly before."
Which roughly translates as : "We know nothing of how the linux dev ecosystem works and do not care."
-
Unlike what the buffoons at Theori published as a "mitigation", the folks at Red Hat actually published a viable mitigation for CopyFail CVE-2026-31431.
Specifically, edit your grub (or whatever you use to load your kernel) configuration to have one of the following arguments:
initcall_blacklist=algif_aead_initinitcall_blacklist=af_alg_initinitcall_blacklist=crypto_authenc_esn_module_initWith such boot arguments to the Linux kernel, the affected bits won't be reachable.
@wdormann They are suboptimal at web design, though.
(First time I see this, I didn’t even know it was possible. It doesn’t change anything to the good they’re doing, obviously, it’s just funny.)
-
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 the thing I don't get about this whole situation is, if they really are genuine in their plight to make the world a better place (which doesn't not preclude making "paid for" products), I don't see why they can't raise awareness of what they perceive is a critical issue without just dropping the PoC. They're mutually exclusive and plenty of people have successfully done exactly that, while holding back the exact details until later. Sure, other people will poke if given vague direction but the damage and panic is done by making it instantly and easily achievable.
Even with the context continually being given and expanded on, it still feels like nothing more than an excuse for attention to "buy our awesome product" through thinly veiled bragging rights.
-
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 if these ai systems are so fast, cheap, and omnipotent, it seems like they couldve used "xint" to determine that downstream hadn't patched yet
ai changes the equation, okay fair enough. we were also completely naive, our powerful ai kept us out of the loop🤨 -
@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?
This post got into my head. I think you're right, the days of coordination are over
So I wrote it down
https://opensourcesecurity.io/2026/05-vulnerability-economics/ -
This post got into my head. I think you're right, the days of coordination are over
So I wrote it down
https://opensourcesecurity.io/2026/05-vulnerability-economics/@joshbressers @gregkh @wdormann @Viss Nice, just my conclusion: if embargoes ever made sense, that time is over.
#curl notifies distros about upcoming CVEs, but a good part of curl applications will notice them a year (or ten) from now. Maybe. They probably just update to a newer version without reading the CVEs.
️(I hold special views about LTS releases with hand-picked patches - but maybe another time
) -
This post got into my head. I think you're right, the days of coordination are over
So I wrote it down
https://opensourcesecurity.io/2026/05-vulnerability-economics/@joshbressers @gregkh @wdormann @Viss aren’t the "users" missing from the equation? In the end we do it for them and we need them to fix their systems, and we need it to be easy for them to fix their systems.
Also there are a lot of open source companies, whether software developers, support providers, integrators, administrators, or a combination.
Also governments which are users, regulators, contributors…
Economics are hard indeed
-
@joshbressers @gregkh @wdormann @Viss Nice, just my conclusion: if embargoes ever made sense, that time is over.
#curl notifies distros about upcoming CVEs, but a good part of curl applications will notice them a year (or ten) from now. Maybe. They probably just update to a newer version without reading the CVEs.
️(I hold special views about LTS releases with hand-picked patches - but maybe another time
)@icing @joshbressers @gregkh @wdormann @Viss All these arguments may or not be true, but I still do not quite see why - for copy fail - downstream open-source projects such as Debian were not notified during the embargo time?
-
@icing @joshbressers @gregkh @wdormann @Viss All these arguments may or not be true, but I still do not quite see why - for copy fail - downstream open-source projects such as Debian were not notified during the embargo time?
@uecker @icing @joshbressers @wdormann @Viss There was no "embargo time". And again, Linux does not notify anyone because if we did, we would have to notify everyone.
It's as if no one reads my long posts about this topic explaining it all... -
@joshbressers @gregkh @wdormann @Viss aren’t the "users" missing from the equation? In the end we do it for them and we need them to fix their systems, and we need it to be easy for them to fix their systems.
Also there are a lot of open source companies, whether software developers, support providers, integrators, administrators, or a combination.
Also governments which are users, regulators, contributors…
Economics are hard indeed
@corsac @joshbressers @wdormann @Viss Linux makes it very "easy", just update your kernel to the newest version. What's preventing that from happening for your systems? -
@corsac @joshbressers @wdormann @Viss Linux makes it very "easy", just update your kernel to the newest version. What's preventing that from happening for your systems?
@gregkh @joshbressers @wdormann @Viss End users in IT systems either large or small corps, administrations etc. don’t just get their kernel from kernel.org and rebuild them. They use kernel binaries, usually from a distribution or maybe rebuilt from by their IT.
Most the various containers runtime similarly run on distro kernels.
Not sure the ratio of running kernels coming straight from kernel.org but I’d guess small -
@uecker @icing @joshbressers @wdormann @Viss There was no "embargo time". And again, Linux does not notify anyone because if we did, we would have to notify everyone.
It's as if no one reads my long posts about this topic explaining it all...@gregkh @icing @joshbressers @wdormann @Viss "it is not easy to decide who should be on the list, so we can not even have list with Linux distros hat should obviously be on list" argument seems rather unconvincing though.
-
This post got into my head. I think you're right, the days of coordination are over
So I wrote it down
https://opensourcesecurity.io/2026/05-vulnerability-economics/@joshbressers
As a user, I don't care if my software has vulnerabilities, only if it has ones that the attackers know of.But if vulnerabilities are so plentiful, what's the chance of a security researcher finding the same vuln that an attacker would find? Is the idea that findng & reporting vulns makes us all more secure still true?
@gregkh @wdormann @Viss -
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. 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...
@wdormann Don't forget that the kernel didn't coordinate any sort of backports being ready for stable.
The kernel people obviously did coordinate the mainline fix as they communicated the report they received to the maintainer.
If LTS branches can't get fixes like this, just discontinue them.
The only reason we got releases with fixes in is because Eric Biggers stepped up when he saw nobody was doing it.
