So CopyFail CVE-2026-31431 is a thing.

[pauliehedron@infosec.exchange]

@wdormann This was one of the reasons I pushed so hard to standardize on a rolling release version; because it was easier to deal with reverting to a known good version with breakage than trying to keep track of all the CVEs with different distros and whatever kernel they are packaging for what release cadence for a particular flavor/variant/age/release/support.

I'm still behind, but an understandable behind.

[k8ie@toot.mcld.eu]

@wdormann I get that this was supposed to be a huge ad for Xint Code but the sloppy disclosure really just makes them look incompetent

[wdormann@infosec.exchange]

@squalouJenkins
And interestingly, even downgrading to an older kernel (to ensure that nothing got backported into this otherwise vulnerable 6.1.166 kernel) still gives the same results.

[wdormann@infosec.exchange]

@k8ie
Yes, it's clear that it was published as a "Look at us!" vehicle.

But their abysmally bad coordination put every Linux user on the planet at risk, and is clear evidence that they don't care about anybody other than themselves.

[aristot73@infosec.exchange]

@wdormann I wrote about what happens when vulnerability triage (in a broader sense) fails under the pressure from the expected surge of LLM discovered triage in the link below.

I totally missed what you have highlighted here as a case where the CVE, CVD systems fail not because a vuln is not reported but because it is not appropriately (or accurately?) enriched and the report is subsequently lost in the noise.

https://codeberg.org/tzafaar/Buffers_overflow_into_policy/src/branch/main/briefing%20notes/geer-unmitigatable-surprise-llm-age.md

[wdormann@infosec.exchange]

@aristot73
Unless something changes, it won't be the last time this happens with the Linux kernel.

[viss@mastodon.social]

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

[merospit@infosec.exchange]

@wdormann And a CVSS 7.8 won't standout when only 8.0+ typically get patched by OS. LPE are very underrated by CVSS.

[lengau@mastodon.world]

@wdormann

> I have to assume that they also let the AI decide how to do the vulnerability coordination as well.

r/MurderedByWords material right there.

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