So CopyFail CVE-2026-31431 is a thing.

[squaloujenkins@fosstodon.org]

@wdormann I 'll take this as good - even if weird - news.
Less servers to patch...

[wdormann@infosec.exchange]

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_init
initcall_blacklist=af_alg_init
initcall_blacklist=crypto_authenc_esn_module_init

With such boot arguments to the Linux kernel, the affected bits won't be reachable.

[joshbressers@infosec.exchange]

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

[wdormann@infosec.exchange]

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

[joshbressers@infosec.exchange]

@wdormann @Viss I mean, in their defense we're not easy to find outside a very specific bubble

And we have historically been gigantic assholes

[natanbc@mastodon.social]

@squalouJenkins @wdormann This[1] exploit worked on AL2023 `2023.11.20260413`, the modprobe.d + rmmod combo "fixed" it (`bind: No such file or directory`)

[1]: https://gist.github.com/blasty/d7b5d0599b154c9ec83c182acbd56e8b

[wdormann@infosec.exchange]

As mentioned earlier in this thread, the su corruption route was only one possible strategy to be used by this exploit.

Here's another variant of the exploit that doesn't have to rely on such things to achieve its goal.

For example, the simple escalate argument simply removes the password requirement for su'ing to root. There are other payloads also possible.

Such exploits will not have process 'su' launched '/bin/sh IOCs in the syslogs. Perhaps all that is relevant is the alg: No test for authencesn(hmac(sha256),cbc(aes)) (authencesn(hmac-sha256-lib,cbc-aes-aesni)) part. But there's no evidence of what was done.

[wdormann@infosec.exchange]

There's also a C version of it that works quite well. Even supports aarch64.

[gregkh@social.kernel.org]

@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?

[mjdxp@labyrinth.zone]

@wdormann sorry this is off topic, but this is the first time i've ever seen anyone using the stock xfce layout

[brotundspiele@chaos.social]

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

[deftpunk@fosstodon.org]

@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@social.kernel.org]

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

[moses_izumi@fe.disroot.org]

@mjdxp @wdormann
Yeah I always get rid of the dock.
On my latest run I also disabled the start menu, because I prefer the Application Finder program.

[gunstick@mastodon.opencloud.lu]

@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"

[alcastronic@infosec.exchange]

@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_aead is part of the kernel.

[wdormann@infosec.exchange]

@alcastronic
"Good" is a weird way to describe something that only works on some distributions.

[wdormann@infosec.exchange]

@gunstick
The original (and current) CVE entry is merely the commit message.

Which is unintelligible nonsense for anyone other than a Linux kernel developer.

[joshbressers@infosec.exchange]

@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

[wdormann@infosec.exchange]

@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 flashy copy.fail writeup 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: