So CopyFail CVE-2026-31431 is a thing.
-
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 sorry this is off topic, but this is the first time i've ever seen anyone using the stock xfce layout -
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 And that's why you don't cherry pick bugfixes. If the Linux kernel team says they can't tell for sure if a bug might be a security issue, how do Redhat, Debian, Canonical etc. have the hubris to think they are better at that?
My distros kernel was fixed on 11.4.2026, just hours after the kernel team released their fix. I use Arch by the way.
-
@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 just to clarify: In your view, would it have been equally fine to announce without contacting the Linux security team?
-
@gregkh @joshbressers @wdormann @Viss So just to clarify: In your view, would it have been equally fine to announce without contacting the Linux security team?
@deftpunk @joshbressers @wdormann @Viss no one did contact the kernel security team before they announced this. It was nice enough that they sent us a bug report and we got it fixed and pushed out to the latest stable kernel releases. That's all I can ever hope for. -
@wdormann sorry this is off topic, but this is the first time i've ever seen anyone using the stock xfce layout
-
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 did the initial CVE have a CVSS score and LPE written all over it?
The kernel patch I saw only says "revert to previous way of doing things" -
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 The mitigation to block the modules on boot is good. There is one drawback tough - it requires a reboot. Something that may not be immediately feasible in every environment. On RHEL, this is, however, needed, as
algif_aeadis part of the kernel. -
@wdormann The mitigation to block the modules on boot is good. There is one drawback tough - it requires a reboot. Something that may not be immediately feasible in every environment. On RHEL, this is, however, needed, as
algif_aeadis part of the kernel.@alcastronic
"Good" is a weird way to describe something that only works on some distributions. -
@wdormann did the initial CVE have a CVSS score and LPE written all over it?
The kernel patch I saw only says "revert to previous way of doing things"@gunstick
The original (and current) CVE entry is merely the commit message.Which is unintelligible nonsense for anyone other than a Linux kernel developer.
-
@deftpunk @joshbressers @wdormann @Viss no one did contact the kernel security team before they announced this. It was nice enough that they sent us a bug report and we got it fixed and pushed out to the latest stable kernel releases. That's all I can ever hope for.
@gregkh @deftpunk @wdormann @Viss
It's going to be a wild couple of years
I do think you're right that the traditional disclosure model is gone forever
But this one feels different. It was pretty obvious this was going to be a big one. Most CVEs are extremely lame and will never lead to anything
But some are a big deal. And those can get drown in the great CVE garbage patch
I have no idea what to do about those though, especially in open source
-
@gregkh @deftpunk @wdormann @Viss
It's going to be a wild couple of years
I do think you're right that the traditional disclosure model is gone forever
But this one feels different. It was pretty obvious this was going to be a big one. Most CVEs are extremely lame and will never lead to anything
But some are a big deal. And those can get drown in the great CVE garbage patch
I have no idea what to do about those though, especially in open source
@joshbressers @gregkh @deftpunk @Viss
I get it that a lot of the world uses Linux.
But what if...
In an alternate universe, before publication of the flashycopy.failwriteup with public exploit code, the vulnerability was (for example) reported to the linux-distros mailing list, where the major linux distros are present. And they could hear why this particular vulnerability might want to be on their radar more than the rest of the sea of Linux kernel CVEs? (Universality, reliability, to-be-published exploit code, etc.)Would this alternate universe be:
-
@joshbressers @gregkh @deftpunk @Viss
I get it that a lot of the world uses Linux.
But what if...
In an alternate universe, before publication of the flashycopy.failwriteup with public exploit code, the vulnerability was (for example) reported to the linux-distros mailing list, where the major linux distros are present. And they could hear why this particular vulnerability might want to be on their radar more than the rest of the sea of Linux kernel CVEs? (Universality, reliability, to-be-published exploit code, etc.)Would this alternate universe be:
-
-
-
@gregkh @deftpunk @wdormann @Viss
It's going to be a wild couple of years
I do think you're right that the traditional disclosure model is gone forever
But this one feels different. It was pretty obvious this was going to be a big one. Most CVEs are extremely lame and will never lead to anything
But some are a big deal. And those can get drown in the great CVE garbage patch
I have no idea what to do about those though, especially in open source
@joshbressers @gregkh @deftpunk @wdormann @Viss Here is my take. Just publishing it and letting people catch up, without the "disclosure" is ok.
What is not ok is spreading misinformation and trying to make yourself look bigger than it is, yelling "patch now" when no patch exists, etc
Yeah we need to patch. We know. That is a job for our tooling to tell us. Not the people getting social and possibly marketing clout out of it.
-
-
@joshbressers @gregkh @deftpunk @wdormann @Viss Here is my take. Just publishing it and letting people catch up, without the "disclosure" is ok.
What is not ok is spreading misinformation and trying to make yourself look bigger than it is, yelling "patch now" when no patch exists, etc
Yeah we need to patch. We know. That is a job for our tooling to tell us. Not the people getting social and possibly marketing clout out of it.
-
@joshbressers @gregkh @deftpunk @wdormann @Viss I am ok with waiting. That's the job. I am not ok with having to deal with all my management chain coming to me with no context one after the other asking me if we need to panic because they saw it in linkedin.
Or asking me which AI tool we need to buy to find and patch these automatically before they get found, because it is what the marketing in these tell us.
-
@joshbressers @gregkh @deftpunk @wdormann @Viss I am ok with waiting. That's the job. I am not ok with having to deal with all my management chain coming to me with no context one after the other asking me if we need to panic because they saw it in linkedin.
Or asking me which AI tool we need to buy to find and patch these automatically before they get found, because it is what the marketing in these tell us.
@Di4na @joshbressers you need to buy them all!
-
@gregkh @deftpunk @wdormann @Viss
It's going to be a wild couple of years
I do think you're right that the traditional disclosure model is gone forever
But this one feels different. It was pretty obvious this was going to be a big one. Most CVEs are extremely lame and will never lead to anything
But some are a big deal. And those can get drown in the great CVE garbage patch
I have no idea what to do about those though, especially in open source
@joshbressers @deftpunk @wdormann @Viss Honestly, there was nothing "obvious" about this one being a "big one" compared to all of the bugs we get, and fix, on a daily/weekly basis in the kernel.
The ONLY thing different here from those bugfixes, was that someone made a web site, a simple reproducer, and announced it to the world. For 99.9% of the bugs we fix, that are reproducible like this, no one ever does that. That we know of...
In other words, this was just another Tuesday for us.
