So CopyFail CVE-2026-31431 is a thing.
-
@Di4na @gregkh @joshbressers @wdormann @Viss unfortunately I think there a lot of people (IT services) having been burned more badly by updating than not updating. I still think people should do it (especially because mass vulnerability exploitation seems to usually happen for stuff fixes months ago) but still just blaming them for not doing doesn’t work. Not sure it’s really the Linux kernel the concern here though.
@corsac @gregkh @joshbressers @wdormann @Viss I think it is not true, but it is because we do not burn people for not updating
-
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 this may be true for the Linux kernel, especially with the resignation that the Linux CNA will assign a CVE for most reports, but it doesn't align with my anecdotal experience as glibc CNA. It's likely because we have significantly less volume (12 so far this year, with roughly twice as many reports) and we tend to be picky about what we assign to a CVE id to.
I'd argue that the kernel is special here and doesn't represent the ecosystem.
-
@gregkh @joshbressers @wdormann @corsac @Viss
Here is a small thing to think about.
The whole point of cve is to allow you to not update.
That may sound strange but think about it. The whole point is that as long as we do not reveive a massive panic alert from this limited source, then we do not have to update.
This is why it has become so central. Orgs are fundamentally wired against updates.
-
@ariadne @joshbressers @gregkh @wdormann @Viss @andrewnez @Di4na If only we had some sort of... "Open Source" Vulnerability Database.. as a clearing house. Some sort of non-profit org could maintain it probably
someone should get on that
-waits for attacks from angry squirrels-
-
@ariadne @joshbressers @gregkh @wdormann @Viss @andrewnez @Di4na The Vulnerability Lookup folks are working on something close
GCVE-BCP-03 - Decentralized Publication Standard
Decentralized Publication Standard Version: 1.5 Status: Published (for public review) Date: 2026-03-10 Authors: GCVE Working Group BCP ID: BCP-03 This guide is distributed under CC-BY-4.0. Copyright (C) 2025-2026 GCVE Initiative. Introduction This document describes the decentralized publication model that allows GNAs to publish their vulnerability information directly, without relying on a centralized system. It also outlines the access methods GNAs use to distribute published vulnerabilities through various mechanisms.
(gcve.eu)
@Le_suisse @ariadne @gregkh @wdormann @Viss @andrewnez @Di4na
Yes! The #GCVE folks are really on the ball about all this
I would be willing to bet a milkshake they will be one of the more authoritative sources in the future
-
@joshbressers The one case where downstream vendors can still get advance notice? When they're actually directly employing people on the project level security response teams (which is a potentially double edged sword from the project's side, since it means volunteers don't have to do security response without compensation for their time, but risks bringing those dubious corporate incentives you mentioned up to the project level)
I'm not opposed to a company employing people at a given project to get some advanced notice
The devil is in the details, but I think in many cases it could work
-
@joshbressers @ariadne @gregkh @wdormann @Viss @andrewnez @Di4na (that’s the joke)
-
@joshbressers @gregkh @wdormann @Viss this may be true for the Linux kernel, especially with the resignation that the Linux CNA will assign a CVE for most reports, but it doesn't align with my anecdotal experience as glibc CNA. It's likely because we have significantly less volume (12 so far this year, with roughly twice as many reports) and we tend to be picky about what we assign to a CVE id to.
I'd argue that the kernel is special here and doesn't represent the ecosystem.
@siddhesh_p @gregkh @wdormann @Viss
Every project is really its own ecosystem
I think glibc does a really good job with CVEs
But I suspect if you go from 12 a year to 12 a month your process will have to change
It's possible you would adopt the "give it a CVE and move on" approach, or because there is so much attention from the distros you could get some extra help to deal with the volume
-
@joshbressers @ariadne @gregkh @wdormann @Viss @andrewnez @Di4na (that’s the joke)
-
I'm not opposed to a company employing people at a given project to get some advanced notice
The devil is in the details, but I think in many cases it could work
@joshbressers Yeah, I think it's generally a good thing myself (the responsiveness that's desirable for a good SRT isn't reasonable to expect from volunteers, and involving vendor/redistributor employees is one way of addressing that gap). It "just" needs to be done with awareness of the potentially conflicting interests.
-
@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.
To reiterate what he said, they do have a list its everyone, when they publish the CVE.
-
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/sounds like software distributors now get to experience what most users used to experience: all of a sudden a problem that someone else knew about but we didn't needs to be figured out and dealt with urgently. disclosure procedures made the situation more comfortable for the distributors, but not so much for the users, who got the whole story at once and had to react promptly, instead of as a developing story. maybe this new development levels the playing field a little, making things really inconvenient for everyone. that sort of moral justice is not much of a consolation, alas
CC: @gregkh@social.kernel.org @wdormann@infosec.exchange @Viss@mastodon.social
-
@joshbressers Yeah, I think it's generally a good thing myself (the responsiveness that's desirable for a good SRT isn't reasonable to expect from volunteers, and involving vendor/redistributor employees is one way of addressing that gap). It "just" needs to be done with awareness of the potentially conflicting interests.
@ancoghlan @joshbressers I think it would be a good outcome if the new EU laws encouraged companies basing their products on FOSS to set up their own trade orgs to handle maintenance and security response rather than trying to to fob that off on the original volunteers who donated the code but aren't getting paid. There needs to be a way to funnel money back to the people doing work, and making big claims about developer responsibility deflects from the commercial orgs who base products on FOSS
-
@ariadne @joshbressers @gregkh @wdormann @Viss @andrewnez @Di4na If only we had some sort of... "Open Source" Vulnerability Database.. as a clearing house. Some sort of non-profit org could maintain it probably
someone should get on that
-waits for attacks from angry squirrels-
@ra6bit @ariadne @joshbressers @gregkh @wdormann @Viss @andrewnez @Di4na And then we could have spectacular arguments about what to assign those vulnerabilities where finders argue for maxing out everything even when the vuln is unreachable in practice. (*screaming from the curl maintainers in the distance*)
-
@siddhesh_p @gregkh @wdormann @Viss
Every project is really its own ecosystem
I think glibc does a really good job with CVEs
But I suspect if you go from 12 a year to 12 a month your process will have to change
It's possible you would adopt the "give it a CVE and move on" approach, or because there is so much attention from the distros you could get some extra help to deal with the volume
@joshbressers @gregkh @wdormann @Viss I'm not so sure, I just think there's a vast enough distance between the Linux kernel experience and pretty much any other project when it comes to security handling: volume, nature of reports, density of known exploitable issues. etc. that there aren't really any reasonable parallels to be drawn. I wouldn't think of throwing security policies, CVE evaluation or coordinated disclosure out because the kernel can't find a way to do it in a way that they like.
-
@joshbressers @gregkh @wdormann @Viss I'm not so sure, I just think there's a vast enough distance between the Linux kernel experience and pretty much any other project when it comes to security handling: volume, nature of reports, density of known exploitable issues. etc. that there aren't really any reasonable parallels to be drawn. I wouldn't think of throwing security policies, CVE evaluation or coordinated disclosure out because the kernel can't find a way to do it in a way that they like.
@joshbressers @gregkh @wdormann @Viss and $0.02, security policies are pretty much our first line of defence for security issues for the GNU toolchain, where we try to identify clearly what constitutes a security issues. It also makes it clear to users how to use the tools and API securely. I don't think there's a reasonable equivalent for that for the kernel. One could try, but given that it's a privileged program that's involved in everything, it would be a largely pointless effort.
-
@joshbressers @gregkh @wdormann @Viss and $0.02, security policies are pretty much our first line of defence for security issues for the GNU toolchain, where we try to identify clearly what constitutes a security issues. It also makes it clear to users how to use the tools and API securely. I don't think there's a reasonable equivalent for that for the kernel. One could try, but given that it's a privileged program that's involved in everything, it would be a largely pointless effort.
@joshbressers @gregkh @wdormann @Viss but I'd love to see someone trying, it would be an interesting grad research project I think.
-
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 but it affects only systems with local users that can run malicious code. and this is only hosters of virtual users, in general. the most systems are not the case to concern with this "vulnerability".
common users and servers that don't use virtualization for third-party clients may do just nothing about this. this is not their case. -
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/Interesting take, and probably more right than wrong. I particularly like the last paragraph. One thing to keep in mind in this brave new world:
"My only real suggestion is try not to burn yourself out and be nice to each other. Everyone is going to have it rough, it’s not just you. We probably need a support group or something."
-
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 can confirm. in alpine we had to figure out which stable kernels already had a backport. the disclosure was not well executed.
