Conversation

Notices

1. Embed this notice
   Will Dormann (wdormann@infosec.exchange)'s status on Friday, 01-May-2026 04:39:22 JST Will Dormann

   So CopyFail CVE-2026-31431 is a thing.

   If you're on the Ubuntu platform, 26.04 is not affected. 18.04 through 25.10 are indeed affected, but no fixes are available.

   If you're on another platform, check with your vendor for update availability.

   • Embed this notice
     Will Dormann (wdormann@infosec.exchange)'s status on Friday, 01-May-2026 04:39:20 JST Will Dormann

     in reply to

     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...

   • Embed this notice
     Will Dormann (wdormann@infosec.exchange)'s status on Friday, 01-May-2026 04:39:21 JST Will Dormann

     in reply to

     Or RHEL.
     I suspect that some people use that?

   • Embed this notice
     Will Dormann (wdormann@infosec.exchange)'s status on Friday, 01-May-2026 04:39:21 JST Will Dormann

     in reply to

     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 module as 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.

   • Embed this notice
     Will Dormann (wdormann@infosec.exchange)'s status on Friday, 01-May-2026 04:39:21 JST Will Dormann

     in reply to

     If you're curious about IOCs for copyfail, look in syslog for:
     NET: Registered PF_ALG protocol family
     for attempts to exploit copyfail on systems that use the vulnerable code as a module. For systems that have the vulnerable code compiled into the kernel, like RHEL, you'll see this line on every boot.
     And at least for this particular flavor of exploit, a wall-clock nearby:
     process 'su' launched '/bin/sh with NULL argv: empty string added`
     is an indication of successful exploitation.

     But it's worth noting that the "process launched" stuff is merely what the ITW PoC will leave behind. More clever exploitation may not be as obvious.

     Infoseepage repeated this.
   • Embed this notice
     Will Dormann (wdormann@infosec.exchange)'s status on Friday, 01-May-2026 04:39:22 JST Will Dormann

     in reply to

     If you're using an obscure distro like "Debian", you may not have a fix available.

   • Embed this notice
     Alexandre Oliva (lxo@snac.lx.oliva.nom.br)'s status on Monday, 04-May-2026 02:54:51 JST Alexandre Oliva

     in reply to

     • Viss
     • Greg K-H
     • Josh Bressers
     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
     
   • Embed this notice
     Josh Bressers (joshbressers@infosec.exchange)'s status on Monday, 04-May-2026 02:54:53 JST Josh Bressers

     in reply to

     • Viss
     • Greg K-H

     @gregkh @wdormann @Viss

     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/

   • Embed this notice
     Will Dormann (wdormann@infosec.exchange)'s status on Monday, 04-May-2026 02:54:54 JST Will Dormann

     in reply to

     • Viss
     • Josh Bressers

     @joshbressers @Viss
     If only there were human beings out there who had any sort of experience with coordinating vulnerabilities... 😂

   • Embed this notice
     Greg K-H (gregkh@social.kernel.org)'s status on Monday, 04-May-2026 02:54:54 JST Greg K-H

     in reply to

     • Viss
     • Josh Bressers
     @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? :)
   • Embed this notice
     Josh Bressers (joshbressers@infosec.exchange)'s status on Monday, 04-May-2026 02:54:55 JST Josh Bressers

     in reply to

     • Viss

     @Viss @wdormann every AI vulnerability company wants to find something juicy, and have no idea how to coordinate the findings

   • Embed this notice
     Viss (viss@mastodon.social)'s status on Monday, 04-May-2026 02:54:56 JST Viss

     in reply to

     @wdormann cves turning into marketing vehicles for every company thats a cna is also undoubtedly creating problems in this vein