Post B5q3MlzzdAcGiwtuqW by wdormann@infosec.exchange
(DIR) More posts by wdormann@infosec.exchange
(DIR) Post #B5p5ymWQ8kCI6IMOcy by wdormann@infosec.exchange
0 likes, 0 repeats
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.
(DIR) Post #B5p5ymjtKeyMm4f9cm by wdormann@infosec.exchange
0 likes, 0 repeats
If you're using an obscure distro like "Debian", you may not have a fix available.
(DIR) Post #B5p5ymxMWZkRRqxuca by wdormann@infosec.exchange
0 likes, 0 repeats
Or RHEL.I suspect that some people use that?
(DIR) Post #B5p5yn7duLyHxjm7e4 by wdormann@infosec.exchange
1 likes, 2 repeats
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 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.
(DIR) Post #B5p5ync850MFUI2TAG by wdormann@infosec.exchange
0 likes, 0 repeats
If you're curious about IOCs for copyfail, look in syslog for:NET: Registered PF_ALG protocol familyfor 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.
(DIR) Post #B5q3MlYhGemXMI87Ie by wdormann@infosec.exchange
1 likes, 0 repeats
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...
(DIR) Post #B5q3MlzzdAcGiwtuqW by wdormann@infosec.exchange
0 likes, 0 repeats
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.
(DIR) Post #B5qGZOl0eXMboHF7YG by snowyfox@deadinsi.de
0 likes, 1 repeats
.
(DIR) Post #B5rP1XQX0RSVb9YN4C by Viss@mastodon.social
0 likes, 0 repeats
@wdormann cves turning into marketing vehicles for every company thats a cna is also undoubtedly creating problems in this vein
(DIR) Post #B5rP1XoHa8SQmofL5U by joshbressers@infosec.exchange
0 likes, 0 repeats
@Viss @wdormann every AI vulnerability company wants to find something juicy, and have no idea how to coordinate the findings
(DIR) Post #B5rP1Y0KrK6BOCIxsG by wdormann@infosec.exchange
0 likes, 0 repeats
@joshbressers @Viss If only there were human beings out there who had any sort of experience with coordinating vulnerabilities... 😂
(DIR) Post #B5rP1YGzrNQUDs6GqO by gregkh@social.kernel.org
0 likes, 0 repeats
@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? :)
(DIR) Post #B5rP1YdKWLI5L8Y6ee by zmanion@infosec.exchange
0 likes, 0 repeats
@gregkh @joshbressers @wdormann @Viss so there's absolutely no middle ground? When there is clearly a bug with security impact, give the distros list a week notice (two weeks max, per their policy). If it leaks, outcome is no worse than not notifying distros. The researcher can even do it instead of the kernel. At scale (Linux!) this seems like a Pareto distribution: major distros cover disproportionally most users.
(DIR) Post #B5rP1YmBzONbmchBT6 by gregkh@social.kernel.org
1 likes, 0 repeats
@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?
(DIR) Post #B5ul5sDoPjvViTxLjE by joshbressers@infosec.exchange
0 likes, 0 repeats
@gregkh @wdormann @Viss This post got into my head. I think you're right, the days of coordination are overSo I wrote it downhttps://opensourcesecurity.io/2026/05-vulnerability-economics/
(DIR) Post #B5ul5sVtKWO8cYPmuO by wolf480pl@mstdn.io
0 likes, 0 repeats
@joshbressersAs 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
(DIR) Post #B5unsY4mIu1BKk4J0q by ariadne@social.treehouse.systems
0 likes, 0 repeats
@joshbressers @gregkh @wdormann @Viss @andrewnez @Di4na it would be cool if vulnerability databases could synchronize with each other using activitypub or similar :)
(DIR) Post #B5upeDHH2ErOgNCmvY by ra6bit@infosec.exchange
0 likes, 0 repeats
@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-
(DIR) Post #B5uqazCf0UN47J4YeO by Le_suisse@social.gerbet.me
0 likes, 0 repeats
@ariadne @joshbressers @gregkh @wdormann @Viss @andrewnez @Di4na The Vulnerability Lookup folks are working on something closehttps://gcve.eu/bcp/gcve-bcp-03/
(DIR) Post #B5vUjSZbgpAngpOv2m by gregkh@social.kernel.org
1 likes, 0 repeats
@joshbressers I will quote this in many presentations in the future because it is so true:"The Kernel assigns lots of CVEs. They say it’s because they don’t really know how the Kernel is being used, so they err on the side of caution. Companies hate this because they have to deal with a lot of CVEs. Does the Kernel do this because it’s easier or do they have some sort of secret nefarious reason? Probably because it’s just easier and they have zero downside to disclosing and moving on. "RE: https://infosec.exchange/@joshbressers/116507930206819253
(DIR) Post #B5vYHGmwJPMCqcRzrk by lxo@snac.lx.oliva.nom.br
0 likes, 0 repeats
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
(DIR) Post #B5vazCMML4ivlK5mz2 by buherator@infosec.place
0 likes, 0 repeats
@gregkh @joshbressers What you are describing is called a "negative externality".
(DIR) Post #B5vazCpQazyZDTh0IC by wolf480pl@mstdn.io
0 likes, 0 repeats
@buherator @joshbressers @gregkh I wouldn't call it an externality, since it only affects those who use Linux.It's not like you had a perfectly peaceful software ecosystem and suddenly someone started making Linux, which makes you suffer even if you don't use Linux.No, it only hurts you if you do use it, and the alternative is no Linux at all.
(DIR) Post #B5wV8APmX9vdlnXwe0 by ariadne@social.treehouse.systems
0 likes, 0 repeats
@wdormann can confirm. in alpine we had to figure out which stable kernels already had a backport. the disclosure was not well executed.