For context, the author of the linked post, Sam James, is a Gentoo developer.
Anyway, this is a disaster. It was extremely irresponsible to share the exploit with the world before the distributions shipped the fix. Who knows how many shared hosting providers were hacked with this.
It's also worrying that it seems there's no communication between the kernel security team and distribution maintainers. One would hope that the former would notify the latter, but apparently it's the responsibility of whoever finds the vulnerability.
show comments
semiquaver
> Note that for Linux kernel vulnerabilities, unless the reporter chooses
to bring it to the linux-distros ML, there is no heads-up to
distributions.
Why would they imply it is incumbent on the reporter to liaise with distributions? That seems to assume a high level of familiarity with the linux project. Vulnerability reporters shouldn’t be responsible for directly working with every downstream consumer of the linux kernel, what’s the limiting principal there? Should the reporter also be directly talking to all device manufacturers that use Linux on their machines?
IMO reporter did more than enough by responsibly disclosing it to linux and waiting for a patch to land.
Aren’t there people in the linux project itself with authority over and responsibility for security vulnerabilities? One would think they would be the ones notifying downstream distros…
show comments
iTokio
The most interesting exchange, related to disclosure, is this one:
> Nope, sorry, we are NOT allowed to notify anyone about anything "ahead
of time" otherwise we will have to tell everyone about everything.
That's the only policy by which all the legal/governmental agencies
have agreed to allow us to operate in, so we are stuck with it.
greg k-h
show comments
whatevaa
Stop blaming the reporter. Start asking kernel to fix their process. Linux kernel is no longer a toy project, it has full time employees employed by various companies. They should have handled notifying distributions. Not some rando.
show comments
GranPC
Just for what it's worth, I just pushed an eBPF-based workaround for people who are running kernels in which AF_ALG is linked directly into the kernel and not as a module: https://github.com/Dabbleam/CVE-2026-31431-mitigation
I am running this in production right now and it mitigates the attack, with no unexpected side-effects as far as I can see.
samagragune
A make-me-root bug sitting in the kernel since 2017 and the LTS branches still don't have a clean backport. That's a long window for anything running 6.12 or older
sersi
Interesting comment by Greg Kroah-Hartman when asked why the kernel team doesn't notify distros directly
> Nope, sorry, we are NOT allowed to notify anyone about anything "ahead
of time" otherwise we will have to tell everyone about everything.
That's the only policy by which all the legal/governmental agencies
have agreed to allow us to operate in, so we are stuck with it.
I'd be interested in knowing more about that policy... Seems that there should be exceptions for the major distros.
Of course, major distros who have contracts with SLA could also pay for someone to be on the kernel security team and get a heads up like that..
show comments
KingMachiavelli
`nosuid` and probably `nodev` should IMO be the default filesystem mount options.
`/dev` is already a special devtmpfs and the initrd minimal /dev can just explicitly mount the initrd tmpfs rootfs with `dev` and `suid` if necessary.
Letting SUID binaries just "exist" anywhere is a stupendous security issue. What if you mount some external storage medium, how are you to verify that none of the SUID binaries on that block device are malicious.
Additionally, this exploit appears to only work if the user executing the SUID binary can also read the SUID binary. There's no reason for non-root users to have read on a SUID binary.
NixOS does this correctly. No SUID in the normal package installation directory `/nix/store` and no package leakage outside of that no `nosuid` can safety be used on all other mountpoints. The exception is just a single-purpose `/run/wrappers.$hash` directory that safety contains executable ONLY SUID wrappers.
What's interesting is that their website is also down right now. These seem like special-timed DDos attacks so maintainers cannot communicate the issue well.
show comments
ectospheno
The Bleeping Computer link below mentions a potential remedy until a patch is ready.
For context, the author of the linked post, Sam James, is a Gentoo developer.
Anyway, this is a disaster. It was extremely irresponsible to share the exploit with the world before the distributions shipped the fix. Who knows how many shared hosting providers were hacked with this.
It's also worrying that it seems there's no communication between the kernel security team and distribution maintainers. One would hope that the former would notify the latter, but apparently it's the responsibility of whoever finds the vulnerability.
> Note that for Linux kernel vulnerabilities, unless the reporter chooses to bring it to the linux-distros ML, there is no heads-up to distributions.
Why would they imply it is incumbent on the reporter to liaise with distributions? That seems to assume a high level of familiarity with the linux project. Vulnerability reporters shouldn’t be responsible for directly working with every downstream consumer of the linux kernel, what’s the limiting principal there? Should the reporter also be directly talking to all device manufacturers that use Linux on their machines?
IMO reporter did more than enough by responsibly disclosing it to linux and waiting for a patch to land.
Aren’t there people in the linux project itself with authority over and responsibility for security vulnerabilities? One would think they would be the ones notifying downstream distros…
The most interesting exchange, related to disclosure, is this one:
https://www.openwall.com/lists/oss-security/2026/05/01/3
> Nope, sorry, we are NOT allowed to notify anyone about anything "ahead of time" otherwise we will have to tell everyone about everything. That's the only policy by which all the legal/governmental agencies have agreed to allow us to operate in, so we are stuck with it.
greg k-h
Stop blaming the reporter. Start asking kernel to fix their process. Linux kernel is no longer a toy project, it has full time employees employed by various companies. They should have handled notifying distributions. Not some rando.
Just for what it's worth, I just pushed an eBPF-based workaround for people who are running kernels in which AF_ALG is linked directly into the kernel and not as a module: https://github.com/Dabbleam/CVE-2026-31431-mitigation
I am running this in production right now and it mitigates the attack, with no unexpected side-effects as far as I can see.
A make-me-root bug sitting in the kernel since 2017 and the LTS branches still don't have a clean backport. That's a long window for anything running 6.12 or older
Interesting comment by Greg Kroah-Hartman when asked why the kernel team doesn't notify distros directly
> Nope, sorry, we are NOT allowed to notify anyone about anything "ahead of time" otherwise we will have to tell everyone about everything. That's the only policy by which all the legal/governmental agencies have agreed to allow us to operate in, so we are stuck with it.
I'd be interested in knowing more about that policy... Seems that there should be exceptions for the major distros.
Of course, major distros who have contracts with SLA could also pay for someone to be on the kernel security team and get a heads up like that..
`nosuid` and probably `nodev` should IMO be the default filesystem mount options. `/dev` is already a special devtmpfs and the initrd minimal /dev can just explicitly mount the initrd tmpfs rootfs with `dev` and `suid` if necessary.
Letting SUID binaries just "exist" anywhere is a stupendous security issue. What if you mount some external storage medium, how are you to verify that none of the SUID binaries on that block device are malicious.
Additionally, this exploit appears to only work if the user executing the SUID binary can also read the SUID binary. There's no reason for non-root users to have read on a SUID binary.
NixOS does this correctly. No SUID in the normal package installation directory `/nix/store` and no package leakage outside of that no `nosuid` can safety be used on all other mountpoints. The exception is just a single-purpose `/run/wrappers.$hash` directory that safety contains executable ONLY SUID wrappers.
Unrelated but also a CVE that popped up for ProFTPd: https://www.openwall.com/lists/oss-security/2026/05/01/4
What's interesting is that their website is also down right now. These seem like special-timed DDos attacks so maintainers cannot communicate the issue well.
The Bleeping Computer link below mentions a potential remedy until a patch is ready.
https://www.bleepingcomputer.com/news/security/new-linux-cop...
What's really sad about Copy Fail is that it doesn't seem to work on Android. This is a purely bad situation for Linux.
Neither was NixOS.
https://discourse.nixos.org/t/is-nixos-affected-by-copy-fail...
Related:
Copy Fail
https://news.ycombinator.com/item?id=47952181
Ubuntu has patches out, tested before and after patching.
`initcall_blacklist` is a thing.
Was not disclosed to stagex, and I expect a lot of linux distros. Thankfully we were already on kernel 7.0 so not impacted
Welcome to AI first world, everything is about fail and repriced.
I believe this is the side effect of having upstream manage the CVE process.
The distros dont get any involvement until release, welcome to the suck.
Seems silly. How many distros need to be notified? There are hundreds.
Hyperbola GNU was save because they still use Python 3.8 for both political and stable reasons.
huh somehow seeing people not using ai to work is like wow moment which i cherish a lot these days
Hey Xint Code / tylerni7 <https://news.ycombinator.com/threads?id=tylerni7>, maybe you should improve your disclosure process as well? Maybe make it mandatory for users of your tool?
I have checked all the servers (bookworm, bullseye) that I manage, and none of them have the algif_aead module loaded.
Seems not fatal to all non-patched systems.