Birbla

Join the discussion

Write your take first — we'll ask for email only when you're ready to publish.

Sign in
  • Hacker News
  • For mitigation, the page currently basically just says:

    > Update your distribution's kernel package to one that includes mainline commit a664bf3d603d

    But it isn't very clear to me what Kernel version you can expect that to be in. For Arch/CachyOS, the patch seems to be included in 6.18.22+, 6.19.12+ and 7.0+. If you're on any of the lower versions in the same upstream stable series, you're likely vulnerable right now. Some distro kernels may include the fix in other versions, so check for your distribution.

    by embedding-shape
  • 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

    by kro
  • 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:
    running a search for commit a664bf3d603d's commit message:

        git log --all --grep 'crypto: algif_aead - Revert to operating out-of-place' '--format=%H' | xargs -I '{}' git tag --contains '{}' | sort -u
    outputs these tags as having the fix:

        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
    by nh2
  • I wasn't able to unload algif_aead on RHEL 9/10 because it's built in, rather than a module.

    So here the next-best thing I found: Disable AF_ALG via systemd. Needs drop-ins for all exposed services. Here an Ansible playbook that covers ssdh and user@, which are the main ones usually.

    https://gist.github.com/m3nu/c19269ef4fd6fa53b03eb388f77464d...

    by m3nu
  • 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.
    by yrro
  • 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?
    by pkoiralap
  • 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.
    by byron3256
  • So this replaces a SUID binary, in order to run as PID 0. The website claims it can escape "Kubernetes / container clusters" and "CI runners & build farms" but I don't see anything supporting the claim it can escape a container (or specifically, a user namespace).

    I ran the exploit in rootless Podman, and predictably it doesn't escape the container.

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

    by progval
  • 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.
    by embedding-shape
  • 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.
    by CGamesPlay
  • Their PoC does as you say, but is built upon arbitrary modification of the page cache, which could be abused for the other things
    by amusingimpala75
  • 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.
    by rcxdude
  • 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.
    by tardedmeme
  • 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.

    by layer8
  • > 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.

    by Twirrim
  • >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."

    by john_strinlai
  • Quickly dove into this.

    1. Yes, it's real.

    2. Current chain can write any arbitrary content to any user-readable file (into the page cache).

    3. Current chain relies on an available target suid binary that you can open() as a lowpriv user.

    4. Current exploit relies on that binary being /bin/su and then being able to execve(/bin/sh, 0, 0) (which doesn't work on alpine, etc.). The former is easily replaced in the code. The latter needs a rebuilt payload ELF (also easy).

    5. The authors say they have other chains (including ones that allow container escapes). I believe them.

    6. A mildly de-minified PoC for Alpine with a new payload ELF is at hackerspace[pl]/~q3k/alpine.py . You'll need /bin/ping from iputils. This should be now somewhat reliable on any distro that has a `/bin/sh` and any setuid-and-readable binary (you'll just need to find it on your own).

    by q3k
  • 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...

    by q3k
  • The page itself seems vibecoded and a bit of an advertisement, but it does look like the vulnerability is real and high risk. It does explain the big security update I just got, guess I'll prioritize updating today.
    by phreack
  • With vibe coding, html is a visualiation tool. not sure if i get your problem with that?
    by AntiUSAbah
  • 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.
    by angry_octet
  • 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.
    by 2001zhaozhao
  • Good thing nobody is silly enough to let fully autonomous AI agents run as regular users on these affected operating systems. That could be disastrous given a zero day prompt injection technique.
    by jesse_dot_id
  • Good thing we haven't normalized installing things with curl | sh
    by ryandrake
  • I don't see what the issue is, my agent is already running as root.
    by chromacity
  • LPE = local privilege escalation

    Too many darn acronyms. This one wasn't too hard to figure out from context but I wish people would define acronyms before using them!

    by hackernudes
  • 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.
    by 1970-01-01
  • Good writing for a broad audience requires it. Unfortunately the LLMs don't tend to adopt this guideline.
    by jjordan
  • 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

    by ButlerianJihad
  • 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...

    by arcfour