It seems there was some kind of confusion during the disclosure process, because the vendors aren't treating this vulnerability as serious and it remains unpatched in many distros. https://access.redhat.com/security/cve/cve-2026-31431 "Moderate severity", "Fix deferred" https://security-tracker.debian.org/tracker/CVE-2026-31431 https://ubuntu.com/security/CVE-2026-31431 https://www.suse.com/security/cve/CVE-2026-3143…
I'm schocked that ubuntu is aware of this and the prv lts is not patched yet :|
As someone who works on the Linux kernel's cryptography code, the regularly occurring AF_ALG exploits are really frustrating. AF_ALG, which was added to the kernel many years ago without sufficient review, should not exist. It's very complex, and it exposes a massive attack surface to unprivileged userspace programs. And it's almost completely unnecessary, as userspace already has its own cryptography code to use. Th…
iwd requires CONFIG_CRYPTO_USER_API_AEAD, so disabling this would break Wi-Fi for a lot of people.
Seems like distros consider it a medium risk because it doesn't involve remote code execution and requires local access. Though it allows local root privilege escalation which is considered high priority. https://ubuntu.com/security/cves/about#priority > Medium: A significant problem, typically exploitable for many users. Includes network daemon denial of service, cross-site scripting, and gaining user privileges.
if your model is that linux is just about single-user desktops, this local exploit isn't too bad. or if your model is nothing but DB servers or the like. mystifying to me that shared, multi-user machines are not thought of. for instance, I administer a system with 27k users - people who can login. even if only 1/10,000 of them are curious/malicious/compromised, we (Canadian national research HPC systems) are at risk.…
Not to bad? So we just threat linux overall as a single user system or what?
This is amazing. Page says it works on RHEL 14.3, which doesn’t exist. Current RHEL is 10.x, this must’ve been done in a TARDIS.
ugh sorry should be fixed. There was some scrambling to get more info together to explain the issue (and yes, obviously marketing), so there are some minor mistakes. Thanks for pointing it out!
Hope the 'marketing' had the desired effect. This entire article of pure AI noise was an absolute slog to get through to get to useful information. I have no idea how you view that as positive advertising.
The page itself seems vibecoded and a bit of an advertisement, but it does look like the vulnerability is real and high risk. It does explain the big security update I just got, guess I'll prioritize updating today.
With vibe coding, html is a visualiation tool. not sure if i get your problem with that?
Why is this available in the kernel on a box that does not use ipsec? should this be compile time enabled module instead than a generic solution?
The design philosophy of mainstream Linux distros is not like OpenBSD. Linux distros go to market as maximally capable, maximally interoperable, and maximally available for whatever the users want to do. So there is a lot of "shovelware" that is unnecessarily installed with your base system. A lot of services are enabled that you don't need. A lot of kernel modules are loaded or ready to spring into action as soon as…
Thanks for the explanation. I am wondering if it is possible or does it make sense to have a modular linux that does not have these attack surfaces enabled by default. Alpine is my default solution for most Linux use cases (except when I need GPU support).
It's worth pointing out that you cannot, definitionally, get "real UID 0" in a "rootless" container, because then it wouldn't be a rootless container. This is relevant because this exploit doesn't claim to be able to bypass user namespaces, and that getting "real UID 0" would be a different exploit.
The underlying exploit allows writing arbitrary values to the page cache, independent of any namespacing, so it should be assumed to allow container escapes even if the given PoC code doesn't do that.
That's fair (although it doesn't have anything to do with getting "real root" in a userns in that case). I guess one approach would be something like modifying the host's logrotate binary and waiting for it to trigger, or something like that. Would escape the container to root on the host directly. I imagine it wouldn't be a sure thing to pull off, either, but definitely straightforward enough that any APT should be asking Claude to develop it.
As someone who works on the Linux kernel's cryptography code, the regularly occurring AF_ALG exploits are really frustrating. AF_ALG, which was added to the kernel many years ago without sufficient review, should not exist. It's very complex, and it exposes a massive attack surface to unprivileged userspace programs. And it's almost completely unnecessary, as userspace already has its own cryptography code to use. Th…
Removing this will make the friendly spooks at NSA very sad....
No, it'd make me sad. If they're lurking in there and we can do without, I'm happy to always have my own .config
If this gets removed, they'll creep in somewhere we can't find them for a while.
The design philosophy of mainstream Linux distros is not like OpenBSD. Linux distros go to market as maximally capable, maximally interoperable, and maximally available for whatever the users want to do. So there is a lot of "shovelware" that is unnecessarily installed with your base system. A lot of services are enabled that you don't need. A lot of kernel modules are loaded or ready to spring into action as soon as…
Thanks for the explanation. I am wondering if it is possible or does it make sense to have a modular linux that does not have these attack surfaces enabled by default. Alpine is my default solution for most Linux use cases (except when I need GPU support).
Not "by default", but still Gentoo. My USE= is several lines worth of -this -that -all-the-things. I got rid of wayland, pipewire, pulseaudio, avahi and a shitload of other stuff I don't need.
PulseAudio applications can still produce (but not record) audio through apulse and my handcrafted asoundrc
Please don't rely on my judgement for this being safe for production, but after blacklisting the modules, the provided python exploit failed. Check if the following are modules grep CONFIG_CRYPTO_USER_API /boot/config-$(uname -r) If they are, you can try blacklisting them /etc/modprobe.d/blacklist-crypto-user-api.conf """ blacklist af_alg blacklist algif_hash blacklist algif_skcipher blacklist algif_rng blacklist alg…
Is it built as a module in most distros?
It is built as a module in Debian.
lsmod shows it is not loaded on any of the Trixie or Bookworm machines I have checked, Intel or AMD.