So CopyFail CVE-2026-31431 is a thing.
-
@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?
@gregkh @joshbressers @wdormann @Viss Because it exists and works better than the alternatives: telling nobody (and waiting to see who notices and when) or telling everybody all at once. If you have regulatory requirements to do or not do something, by all means, follow the regs. I'm not claiming any regs implement sound public CVD policy. Also when there is an external finder, the finder could choose to notify distros or follow other coordination paths, in addition to notifying kernel.org.
(I also understand that it's not quite as simple as just dropping a message on the distros list, and I read a Qualys message explaining that they no longer use distros.)
-
@uecker It's easy to make statements, when you do not want to back them with any sort of argument. Just make a statement and put final stop. Product Foo is insecure. Some car manufactured by Baz is not reliable. This argument is unconvincing. I can express that as well...
@krzk I think this is an unfair accusation. I was pointing out that the argument "it is unclear who to put on the list" by itself is a weak argument. I did not think that this needs further explanation as this seems obvious. Maybe there are good reason why it is difficult to maintain such a list, but the thread I commented on did not include those. In any case, I think it is not help to directly accuse people of "FUD" or misinformation in an evolving discussion.
-
-
-
-
@uecker @icing As is pointed, out, this is just a troll, but seriously, "worthy" isn't the issue. Again, you can not have one group "in" and one "out" without real reasons why anyone is "out".
And again, my point remains, "All early release lists leak like a sieve, otherwise why does your government allow it to exist." -
@uecker In case you are sincere: Is Hannah Montana Linux trustworthy? You also forgot Alpine Linux, Suse and and and and in your list, all of which are "serious" distros. What about Android? They run on billions of devices. But they won't patch anyways. Do they get to be in the club? If you inform all of them you might as well inform everyone.
-
@uecker @icing As is pointed, out, this is just a troll, but seriously, "worthy" isn't the issue. Again, you can not have one group "in" and one "out" without real reasons why anyone is "out".
And again, my point remains, "All early release lists leak like a sieve, otherwise why does your government allow it to exist." -
@uecker In case you are sincere: Is Hannah Montana Linux trustworthy? You also forgot Alpine Linux, Suse and and and and in your list, all of which are "serious" distros. What about Android? They run on billions of devices. But they won't patch anyways. Do they get to be in the club? If you inform all of them you might as well inform everyone.
@mormund Sure some of them would seem trustworthy. It might very well be impossible to create a perfect rule about who should or should not be on such a list. But this does not mean that one could not create some reasonable criteria and do a best effort. I disagree with "if you inform some of them you might as well inform everyone" Why should this be the case?
-
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 as Greg has pointed out clearly, it is not the responsibility of the Kernel Security team to inform any distro. The funny thing is that Theori, instead of doing that, claims it is not possible anymore and that any distro should instead use (their?) AI tools to spot critical CVEs for the Linux Kernel. This is just a big marketing fuckup.
-
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 as Greg has pointed out clearly, it is not the responsibility of the Kernel Security team to inform any distro. The funny thing is that Theori, instead of doing that, claims it is not possible anymore and that any distro should instead use (their?) AI tools to spot critical CVEs for the Linux Kernel. This is just a big marketing trick.
-
@wdormann as Greg has pointed out clearly, it is not the responsibility of the Kernel Security team to inform any distro. The funny thing is that Theori, instead of doing that, claims it is not possible anymore and that any distro should instead use (their?) AI tools to spot critical CVEs for the Linux Kernel. This is just a big marketing fuckup.
@Lioh
Vulnerability coordination was clearly only an afterthought.The
copy.failwebsite included screen recordings of 4 Linux distributions being compromised. And at publication time had the audacity to state:Most major distributions are shipping the fix now.
Narrator: No distribution had prepared a fix at publication time, as no distribution was even aware of the vulnerability.
The irony in all of this: Brian Pak (the Theori CEO) got his infosec fame as part of the PPP group at CMU, which is the home of the CERT/CC.
Bonus irony: Brian applied at the CERT/CC in 2011 for a position on the team that does vulnerability coordination when I was there.So to spin things as
The old model simply doesn’t scale anymoreandour best intention was always to improve Linux securityis simply laughable. The goal was a successful publicity stunt. Zero F's were given to the Linux users of the planet.


-
So CopyFail CVE-2026-31431 is a thing.

@wdormann guess it's time to finally update to the latest then
