16 ms·

Dirty Frag: Universal Linux LPE

819 points by flipped 4mo ago

SupLockDef 4mo ago
Where is the famous Linux is so much secure than Windows? I would like to see the same hate comments about Linux than the ones we would see if it was a Windows vulnerability...
baggy_trough 4mo ago
Disclosure Timeline 2026-04-29: Submitted detailed information about the rxrpc vulnerability and a weaponized exploit that achieves root privileges on Ubuntu to security@kernel.org. 2026-04-29: Submitted the patch for the rxrpc vulnerability to the netdev mailing list. Information about this issue was published publicly. 2026-05-07: Submitted detailed information about the vulnerability and the exploit to the linux-distros mailing list. The embargo was set to 5 days, with an agreement that if a third party publishes the exploit on the internet during the embargo period, the Dirty Frag exploit would be published publicly. 2026-05-07: Detailed information and the exploit for the esp vulnerability were published publicly by an unrelated third party, breaking the embargo. 2026-05-07: After obtaining agreement from distribution maintainers to fully disclose Dirty Frag, the entire Dirty Frag document was published.
- flumpcakes 4mo ago
  7 days from disclosure to publishing a how-to guide to get root to the entire planet doesn't scream "responsible" disclosure to me.
  - deleted 4mo ago
    [deleted]
  - bawolff 4mo ago
    Its not the reporter's fault that other people broke the embargo.
    - progval 4mo ago
      They don't have to publish a working exploit as soon as the embargo is broken, though.
      - mike_d 4mo ago
        Why not? There has already been a working exploit floating around, at least now it comes from an authoritative source.
      - john_strinlai 4mo ago
        anyone who will use the exploit maliciously will immediately and trivially be able to create a working exploit.
      - throw0101c 4mo ago
        Perhaps, but if the exploit code is published folks can double-check that they implemented the mitigations properly. If there's no PoC, how can you really be sure?
      - staticassertion 4mo ago
        An exploit was already published.
      - j16sdiz 4mo ago
        The third party posted an exploit.
  - firer 4mo ago
    My immediate reaction was the same. But this is very similar to Copy Fail, and I'm assuming there was an assumption that others might also discover this soon as well. Hence the urgency. At least that's my charitable interpretation.
  - lofaszvanitt 4mo ago
    WTF cares? Publish them without disclosure is the true way, otherwise noone would care about security and your data.
john_strinlai 4mo ago
"Because the embargo has now been broken, no patches or CVEs exist for these vulnerabilities." link: https://github.com/V4bel/dirtyfrag https://github.com/V4bel/dirtyfrag detailed writeup: https://github.com/V4bel/dirtyfrag/blob/master/assets/write-up.md https://github.com/V4bel/dirtyfrag/blob/master/assets/write-... importantly: "Copy Fail was the motivation for starting this research. In particular, xfrm-ESP Page-Cache Write in the Dirty Frag vulnerability chain shares the same sink as Copy Fail. However, it is triggered regardless of whether the algif_aead module is available. In other words, even on systems where the publicly known Copy Fail mitigation (algif_aead blacklist) is applied, your Linux is still vulnerable to Dirty Frag." mitigation (i have not tested or verified!): "Because the responsible disclosure schedule and the embargo have been broken, no patch exists for any distribution. Use the following command to remove the modules in which the vulnerabilities occur." sh -c "printf 'install esp4 /bin/false\ninstall esp6 /bin/false\ninstall rxrpc /bin/false\n' > /etc/modprobe.d/dirtyfrag.conf; rmmod esp4 esp6 rxrpc 2>/dev/null; true" conversation around the mitigation suggests you need a reboot or run this after the above on already-exploited machines: sudo echo 3 > /prox/sys/vm/drop_caches
- progval 4mo ago
  "sudo" in "sudo echo 3 > /prox/sys/vm/drop_caches" does not do anything because only runs echo, not the write. And if a machine is already exploited, it's too late to do just that. You need to rebuild the whole disk image because anything on it could be compromised.
  - john_strinlai 4mo ago
    >And if a machine is already exploited, it's too late to do just that. You need to rebuild the whole disk image because anything on it could be compromised. this is more targeted at the people who run the PoC to see if their machine is vulnerable. just transcribing some relevant stuff from https://github.com/V4bel/dirtyfrag/issues/1 https://github.com/V4bel/dirtyfrag/issues/1 so that people visiting this thread dont need to poke around a bunch of different places.
- dundarious 4mo ago
Tiberium 4mo ago
Do you think with modern LLMs in a few years projects like Linux will have all those low-hanging security bugs fixed? Are we witnessing a transition period, or will nothing change?
- staticassertion 4mo ago
  New vulns are introduced to Linux every day. Fuzzers trigger every single day on Linux. No, nothing will improve here from AI.
  - Muromec 4mo ago
    There is a finite number of bugs and betters tools that find them mean there is less bugs in the code.
    - staticassertion 4mo ago
      We already find bugs constantly in Linux and they go unaddressed, no one even keeps up with syzkaller reports lol AI is neat because it's higher signal but yeah no, we're not getting anywhere close to "safe linux", AI or not.
      - Muromec 4mo ago
        I want to believe, okay
  - alex_duf 4mo ago
    there's an argument to be made that new code will be inspected before being merged and therefore the classes of bugs an LLM is likely to find will not be merged until it's fixed.
- deleted 4mo ago
  [deleted]
- spartanatreyu 4mo ago
  LLMs don't matter, linux's codebase has been growing much faster than it can be secured so this is all inevitable. Transitioning components to rust eliminates certain categories of bugs leaving the rest of the bugs to be dealt with. We'd likely end up needing another language with stronger type and effect systems to eliminate more categories of bugs. Probably something which enforces linear types, capabilities, units of measure types, and effects. And you'd have to update linux itself to switch to capabilities.
miduil 4mo ago
This again does not work under Android, at least in termux compiled with clang/gcc.
- ronsor 4mo ago
  Android has a lot of hardening and sandboxing that desktop Linux doesn't (and won't for UX reasons).
  - miduil 4mo ago
    Yes, it demonstrates that it's possible to harden well - at least for some cases. It appears depending on the environment hardened kernel / runtime environments are pretty much possible to have safeguards working today already.
  - deleted 4mo ago
    [deleted]
  - __float 4mo ago
    > desktop Linux doesn't (and won't for UX reasons) Can you elaborate?
    - danudey 4mo ago
      Not sure what specifically they're referring to, but Android (and iOS) add a lot of sandboxing to ensure that each application can only access its own files, can't access hardware willy-nilly (bluetooth, scanning wifi, etc), can only link against certain libraries, etc. Imagine if Linux only let you run stuff from Flatpak, and if stuff didn't work in Flatpak then too bad for you. Most Linux users would hate it and it would be a mess a lot of the time, so, for user experience (UX) reasons, they don't do it. Android can get away with it because that's been the app paradigm for decades now.
    - akdev1l 4mo ago
      A very comprehensive SELinux deployment for one. SELinux will stop any process in android from loading kernel modules, that’s not allowed. The android permission model as a whole is ultimately backed by SELinux.
BadBadJellyBean 4mo ago
Well this is getting tiresome. I wish there was a less stressful way to get fixes for such bugs. But the cat is out of the bag now. Not criticizing whoever found the bug, of course.
deleted 4mo ago
[deleted]
unethical_ban 4mo ago
Here's a general question, are these vulnerabilities hitting Linux more than BSDs due to hit being a larger target or because its architecture is less secure by design?
- staticassertion 4mo ago
  Larger target.
  - golem14 4mo ago
    in many ways: - more people are using it (assuming macos is in its own bucket perhaps) - bigger surface areas (esp NetBSD has in my limited understanding just less stuff that can go boom) - more churn, ie more new stuff than can be buggy released more often. Of course, because of that, more eyes are on Linux, so I'm not sure where that security tradeoff is.
- ahartmetz 4mo ago
  AFAIU, Linux and the BSDs have basically the same architecture - the BSDs just value secure and simple, understandable code more highly than Linux vs features and performance.
  - angry_octet 4mo ago
    This is really not a correct statement beyond the fact that both are a type of Unix.
    - cluckindan 4mo ago
      Linux is not Unix: it is not derived from AT&T Unix.
      - ahartmetz 4mo ago
        Linux 2.2 or 2.4 or so (possibly only Suse Linux) even had a kernel startup message "Unix compliance testing by UNIFIX" or something, back when Unix was considered more prestigious than Linux. It is / was by some official definition "a Unix", though not "UNIX the trademark by AT&T".
int0x29 4mo ago
I'm curious what broke the embargo. Did it leak or did a third party find it independently?
- john_strinlai 4mo ago
  it was published publicly by an unrelated third party
  - jacobgkau 4mo ago
    They're asking the nature of the third party's discovery/publishing. Someone on the inside who decided to leak it anonymously? Someone else who was able to access some private communication they shouldn't have been able to see? Or a third party who happened to discover the same vulnerability (which seems less unlikely than normal since this is so similar to Copy Fail), but didn't follow disclosure procedures?
    - staticassertion 4mo ago
      The commit for the fix was public. Someone noticed. An exploit was published.
      - ahartmetz 4mo ago
        I think I read on the bug's website that "No fix has been released". I understood that as there is no public fix, but maybe it only means it's not in a tagged version of the kernel and no hotfixed distro kernels have been released?
        danudey 4mo ago
        The patch was posted to the kernel mailing list; someone saw the e-mail, read the patch, figured it out, and published an exploit very soon after.
        tkel 4mo ago
oncallthrow 4mo ago
can this also be used to obtain container escape ?
- synack 4mo ago
  If your container has setuid binaries and these modules are loaded, yes.
  - lights0123 4mo ago
    With the exploits published as-is, you'll only get root inside the container: there's no explicit namespace break, and calling setuid() in a container just gives you root in the container. However, it can be used to modify files that are passed into the container (e.g. Docker run -v), or files that are shared with other containers (e.g. other Docker containers sharing the same layers). kube-proxy with Kubernetes happens to share a trusted binary with containers by default, which is how it can be exploited: https://github.com/Percivalll/Copy-Fail-CVE-2026-31431-Kubernetes-PoC https://github.com/Percivalll/Copy-Fail-CVE-2026-31431-Kuber...
  - miduil 4mo ago
    It's poisoning the filesystem cache, if you don't have a setuid binary handy you just poison anything else that gets executed by the host.
  - awoimbee 4mo ago
    And your containers need to have specific capabilities enabled, which aren't by default on kubernetes and podman.
    - friedr12 4mo ago
      [dead]
  - aaronmdjones 4mo ago
    You don't need any setuid binaries. You could just as easily use the vulnerability to add a job to crontab(5) that causes the cron daemon to run whatever you want as root.
firer 4mo ago
This is very similar in root cause and exploitation to Copy Fail. Which illustrates pretty well something that's lost when relying heavily on LLMs to do work for you: exploration. I find that doing vulnerability research using AI really hinders my creativity. When your workflow consists of asking questions and getting answers immediately, you don't get to see what's nearby. It's like a genie - you get exactly what you asked for and nothing more. The researcher who discovered Copy Fail relied heavily on AI after noticing something fishy. If he had to manually wade through lots of code by himself, he would have many more chances to spot these twin bugs. At the same time, I'm pretty sure that by using slightly less directed prompting, a frontier LLM would found these bugs for him too. It's a very unusual case of negative synergy, where working together hurt performance.
- eqvinox 4mo ago
  No, unless I'm misreading it it's the *same* root cause: high 32 bits of Extended ESN in IPsec == authencesn module/cipher mode. The wrong thing got fixed for copy.fail, because people jumped to blame AF_ALG. [ed.: yes it's the same authencesn issue. https://github.com/V4bel/dirtyfrag/blob/892d9a31d391b7f0fccb333855f6289507186748/exp.c#L210 https://github.com/V4bel/dirtyfrag/blob/892d9a31d391b7f0fccb... it doesn't say authencesn in the code, only in a comment, but nonetheless, same issue.] [ed.2: the RxRPC issue is separate, this is about the ESP one]
  - firer 4mo ago
    There are two vulnerabilities here. The RxRPC one is definitely a different root cause (although caused by a very similar mistake). For the ESP one it's a bit harder to tell. I don't think the wrong thing was fixed, just that there was a very similar bug in almost the same spot. Could be wrong about that though.
    - eqvinox 4mo ago
      (you probably wrote this while I was editing my post.) It's absolutely the same issue in authencesn/ESP. There's another one in RxRPC that is AIUI completely unrelated.
normie3000 4mo ago
So umm... should I rush home and turn off all my computers?
- arcfour 4mo ago
  Are they already vulnerable to RCE as an unprivileged user? Hopefully not. An LPE only allows an attacker who can already execute code on the system to become root. So, bad, yes, but it doesn't mean you are immediately pwned.
  - hughw 4mo ago
    Should I rush to Lambda or ECS and turn off all my containers sharing a host with who the hell knows?
    - tkel 4mo ago
      Like others have said, this will get you root inside the container. It isn't a container escape. File/volume mounts shared across containers would be vulnerable.
    - arcfour 4mo ago
      Firecracker is extremely hardened, so I wouldn't worry about Lambda. As for ECS, getting root doesn't necessarily mean you have a container escape. I think you could escape containers with this exploit, but you would need a different payload than what's published. I could be wrong though. I would assume AWS is pretty on the ball when it comes to handling stuff like this if they didn't have other defenses or mitigations in place already.
    - PhilipRoman 4mo ago
      AFAIK Lambda and everything else will use micro-VMs. No serious company would use a shared kernel design for workloads in different security contexts. (Personally I wouldn't even use the same hardware host, but sometimes sacrifices have to be made)
  - account42 4mo ago
eqvinox 4mo ago
And I ask again: why the f*ck is algif_aead getting all the flak for copy.fail? It's authencesn being stupid. authencesn didn't get fixed. Now we got the results of that, turns out you can access the same (I believe) out of bounds write through plain network sockets. I wish I thought of that, but I didn't. [ed.: I'm referring to the through-ESP issue. The RxRPC one is AIUI completely unrelated.]
xxpor 4mo ago
Linux is a single user system and should be treated as such. Run your services as root. Don't rely on unix user primitives for security.
- wolttam 4mo ago
  Running as root opens you up to a class of vulnerabilities (denial of service, mainly) that you can avoid by not running as root. That said, running every process in its own micro VM is looking more attractive by the minute.
  - xxpor 4mo ago
    Half the point is that you should always assume that there exists a complete LPE bug. But yes, micro VMs are a great idea!
- amarant 4mo ago
  Everything in this comment is wrong.
  - xxpor 4mo ago
    Technically yes. Practically, I disagree.
    - eqvinox 4mo ago
      The part where you run everything as root is particularly stupid. But yes, user isolation has been weakened quite a bit.
- 256_ 4mo ago
  I agree with the general sentiment. I treat anything running arbitrary machine code as if it has full access to a machine. I don't know where you get "run your services as root" from that, though. The principle of least privilege doesn't just apply to running malicious code, but running buggy code whose attack surface is exposed to evil-doers.
- 4mo ago
zepearl 4mo ago
So if I understand correctly 3 modules are involved: - esp4 (kernel config "CONFIG_AF_RXRPC") - esp6 (kernel config "CONFIG_INET_ESP") - rxrpc (kernel config "CONFIG_INET6_ESP") Is this correct?
- eqvinox 4mo ago
  You mixed up the names vs. config options but yes killing those 3 options should make you "safe". No warranty.
  - zepearl 4mo ago
    damn you're right, thx
deleted 4mo ago
[deleted]
ftheplan9 4mo ago
[flagged]
- john_strinlai 4mo ago
  >2026-05-07: After obtaining agreement from distribution maintainers to fully disclose Dirty Frag, the entire Dirty Frag document was published. you think the reporters and the distribution maintainers colluded to... get 5 minutes of attention? that would be exceptionally stupid of the distribution maintainers and destroy all trust.
arian_ 4mo ago
Every time someone finds a universal Linux privilege escalation, somewhere a sysadmin whispers 'this is why we don't run as root' while nervously checking if their containers are actually isolated.
- oncallthrow 4mo ago
  > this is why we don't run as root The entire point is that you can escalate to root
- minimaltom 4mo ago
  This attack class lets you escalate from any user to UID 0. Not running as root won't save you, in fact, this attack is for those processes not running as root. However, if you are in a user namespace where UID 0 doesn't map to system-wide capabilities, and you dont share page cache for the setuid binaries on the system, this attack doesn't lead to LPE.
  - delamon 4mo ago
    setuid binaries are not the only way to get root. E.g. one can change /etc/crontab or /etc/passwd. Or add trojan to /bin/ls and wait until admin type 'ls'
    - quantummagic 4mo ago
      It's not always as easy as you imply. All the attack vectors you mentioned, require root on the host, before you can make the change or install the trojan.
      - delamon 4mo ago
        The attack gives you ability to overwrite any cached page. So you don't need to be root to "edit" /etc/passwd.
        quantummagic 4mo ago
KamiNuvini 4mo ago
Does anyone know whether Debian is vulnerable? I tried the exploit on a Debian 12+Debian 13 machine but wasn't able to reproduce it myself.
- cholmon 4mo ago
  I just tried the exploit on a fresh Debian 13 droplet on digitalocean and it worked.
- thaniri 4mo ago
  I was able to reproduce this issue on kernel 6.12.57+deb13-amd64 running Debian 13 (Trixie), but unable to reproduce it on kernel 6.1.0-42-amd64 running Debian 12 (Bookworm). For anyone not on the security stream of Debian packages for Bookworm, kernel version 6.1.0-42-amd64 is actually immune to copy.fail. Surprising that it looks to be immune to dirtyfrag. If you haven't already patched on the security stream, you can choose any kernel version that kept commit 2b8bbc64b5c2. I am thinking that the same commit might accidentally be keeping certain Debian 12 kernel versions safe from dirtyfrag as well.
- louwrentius 4mo ago
  I tested on a fully up-to-date Debian 13 and the exploit works. The mitigation also works / confirmed.
- deleted 4mo ago
  [deleted]
- Existing4190 4mo ago
  https://security-tracker.debian.org/tracker/CVE-2026-43500 https://security-tracker.debian.org/tracker/CVE-2026-43500 https://security-tracker.debian.org/tracker/CVE-2026-43284 https://security-tracker.debian.org/tracker/CVE-2026-43284
- baggy_trough 4mo ago
  Debian 13 is offering linux-image-6.12.86+deb13 now.
chromacity 4mo ago
If this indeed works on all major distributions, I just continue to be amazed by how irresponsible the maintainers are. We're talking about optional kernel functionality that's presumably useful to something like <0.1% of their userbase, but is enabled by default?... why? This feels like the practice of Linux distros back in 1999 when they'd ship default installs with dozens of network services exposed to the internet. Except it's not 1999 anymore.
- TacticalCoder 4mo ago
  > ... but is enabled by default?... why? We could also wonder why XZ was linked to SSH... But only on systemd-enabled distros (which is a lot of them). Just... Why? And then make sure to call to incompetence, instead of malice and say non-sense like "Sure, it only factually affects systemd distros, but this is totally not related to systemd". All I saw though was a systemd backdoor (sorry, exploit). Now regarding copy.fail that just happened: not all maintainers are irresponsible. And some have, rightfully, bragged that the security measures they preemptively took in their distros made them non vulnerable. But yup I agree it's madness. Just why. And Ubuntu is a really bad offender: it's as if they did a "yes | .." pipe to configure every single modules as an include directly in the kernel. "We take security seriously, look we've got the IPsec backdoor (sorry, exploit) modules directly in the kernel". "There's 'sec' in 'IPsec', so we're backdoored (sorry, secure)".
  - chuckadams 4mo ago
    xz was not directly linked to ssh, and systemd itself was not providing the backdoor. The weakness is embedded into the architecture of glibc (which has spread to other systems like FreeBSD as well): https://github.com/robertdfrench/ifuncd-up https://github.com/robertdfrench/ifuncd-up
    - TacticalCoder 4mo ago
      Sure, but distros not using systemd were not affected.
deleted 4mo ago
[deleted]
eqvinox 4mo ago
If you don't need it (rootless containers), you can disable unprivileged userns to block these two: echo 1 | sudo tee /proc/sys/kernel/apparmor_restrict_unprivileged_userns May also break sandboxes (e.g. browser) though.
deleted 4mo ago
[deleted]
acedTrex 4mo ago
Here we go again
jcims 4mo ago
Tested Amazon Linux 2023 and it doesn't appear to be vulnerable in the default configuration. Would be interested if anyone finds anything different.
CalmBirch127 4mo ago
[dead]
HollowRidge427 4mo ago
[dead]
deleted 4mo ago
[deleted]
deleted 4mo ago
[deleted]
teaearlgraycold 4mo ago
Anyone here with experience providing multi-tenant Linux systems (CI and the like), do providers usually disable kernel modules they don’t need to eliminate attack surface? Every time one of these comes out I wonder if I should be rotating every key in my GitHub CI or PaaS host. So far I haven’t seen any reports from the providers I use that they were pwned by any of these exploits.
- TheDong 4mo ago
  A lot of these multi-tenant CI systems actually run everything in microVMs even if they present it to you as a container. At this point, a microvm can be booted in ~200ms so you don't even have to keep a warm pool, you can just launch em on demand. GitHub CI (actions) uses virtual machines.
ftheplan9 4mo ago
[flagged]
kinow 4mo ago
Just got an email from one HPC I have access in Germany. I guess all HPCs ans services like GH Actions are going to be offline for a bit. I think last time was on a Friday too, so it might be another Friday to organize emails, files, rotate backup/passwords...
hughw 4mo ago
Ran as a fresh new default user in a ubuntu:latest container git clone https://github.com/V4bel/dirtyfrag.git && cd dirtyfrag && gcc -O0 -Wall -o exp exp.c -lutil && ./exp Result: dirtyfrag: failed (rc=3) Good news!
- Havoc 4mo ago
  Wouldn't count on container being a reliable testing platform for this. Loads of stuff - legitimate or otherwise - fails in containers
- stsewd 4mo ago
  I got the same running it inside a container, but got a shell when running it directly in the host. This only shows that the exploit doesn't work inside a container. So, containers aren't vulnerable, or the script needs some adjustments to make it work in containers. Since copy fail can be used to escape containers (https://github.com/Percivalll/Copy-Fail-CVE-2026-31431-Kubernetes-PoC https://github.com/Percivalll/Copy-Fail-CVE-2026-31431-Kuber...), I'm guessing the exploit needs some changes only.
  - cyphar 4mo ago
    The repo you linked works by replacing files that are being used by other privileged containers on the same system. That works for the Kubernetes case (I'm a little surprised they don't use static binaries for their own privileged containers, seems a little dangerous to share any kind of data with untrusted tenants even if it's read-only) but not standalone containers. However, there is a much an easier way of doing a breakout -- you can corrupt the host runc binary in a way analogous to CVE-2019-5736. The next time a container is spawned, the host runc binary will get run as as root and that's that. Ironically, the first version of the protection against this attack I wrote also protected against page cache poisoning (by making a temporary copy of the runc binary during container setup in a sealed memfd and re-execing that) but the runtime cost of copying a 10MB binary at container startup was seen as too expensive by some users[1] so we ended up with a setup that shares the same page cache. I also distinctly remember arguing at the time that something like Dirty Cow could always happen in the future, and the memfd approach was better for that reason -- maybe I should've stuck to my guns more... :/ In practice the solution for containers is to update your seccomp policy to block the vulnerable syscall. [1]: https://github.com/opencontainers/runc/issues/1980 https://github.com/opencontainers/runc/issues/1980
x4132 4mo ago
this is why you don't contact distro mailing list. responsible disclosure is dead.
- zbentley 4mo ago
  At present it looks to me like the embargo was broken by someone identifying the patch as fixing a vulnerability, not someone leaking the mailing list. More information may come out, or I might be missing something, but assuming that the above is accurate, this isn't a problem with responsible disclosure or mailing list opsec; it's a problem with the nature of open source. Right? Or are folks seriously proposing that the patch/mitigations should have been circulated to distro maintainers privately before going to mainline?
  - collinmanderson 4mo ago
    > Or are folks seriously proposing that the patch/mitigations should have been circulated to distro maintainers privately before going to mainline? I always assumed that distro maintainers got early access to patches before going mainline but maybe that’s not true?
    - deleted 4mo ago
      [deleted]
7373737373 4mo ago
Tanenbaum was right
- TZubiri 4mo ago
  Go on...
  - 7373737373 4mo ago
    https://youtube.com/watch?v=oS4UWgHtRDw https://youtube.com/watch?v=oS4UWgHtRDw
Retr0id 4mo ago
Testing the rxrpc vuln on aarch64, I get a kernel data abort, which is interesting. Not looked into the root cause yet!
- Retr0id 4mo ago
  Huh why is this getting downvoted?
thom 4mo ago
After all these years, we finally have enough eyeballs that all bugs are shallow, and it kinda sucks. How many times a week am I going to be updating my kernel from now on?
- brcmthrowaway 4mo ago
  So you think someone is going to break into your house, find your default credentials somehow and get root access?
  - sureglymop 4mo ago
    With physical access, root access is as simple as setting init=/bin/bash in the kernel parameters from a bootloader. No need for credentials or anything.
    - anygivnthursday 4mo ago
      Secure boot and disk enryption are not that unusual nowdays
      - Asraelite 4mo ago
        Secure boot doesn't provide security, just control for device manufacturers. Physical access always means the device is pwned. You can install a keylogger or something similar.
        qrobit 4mo ago
        Secure boot ensures the image you boot was not tampered with. You can't install keylogger without tampering with the image. If you wanted to install physical keylogger, you would need to open the device up, and at least my laptop provides detection of bottom cover removal, meaning the system will ask you for a bios password if the laptop was opened up.
  - thom 4mo ago
deleted 4mo ago
[deleted]
caned 4mo ago
The enforcement of read-only protection for pagecache pages (and the scatterlists and or other structures they point to) seems to be diffuse and incredibly fragile.
baggy_trough 4mo ago
From the 3rd party discloser: https://openwall.com/lists/oss-security/2026/05/07/12 https://openwall.com/lists/oss-security/2026/05/07/12
deleted 4mo ago
[deleted]
cynicalsecurity 4mo ago
Imagine how many undiscovered bugs and exploits exist in Windows.
- tap-snap-or-nap 4mo ago
  Noone has the time given how many windows bugs are already open and active long term.
netheril96 4mo ago
We need an easy way to ensure that only kernel modules in an whitelist can load. I’m tired of blacklisting modules I never need.
lyu07282 4mo ago
Two distro independent LPEs in such a short time, if only all Linux software could be this portable.
infrapilot 4mo ago
[flagged]
- staticassertion 4mo ago
  > The old “quiet patch before disclosure” model may simply not work anymore in the LLM era. It never did. Trawling the Linux commit history is a tried and true method for finding n-days.
mikeweiss 4mo ago
Considering AWS just released patches for Copy Fail for Amazon Linux and Bottlerocket only yesterday.... I imagine it will over a week before we see patches for this. This is especially important to fix on Kubernetes nodes...does anyone have any recommendations for mitigating this issue before a patch is released?
QuietLedge375 4mo ago
[dead]
deleted 4mo ago
[deleted]
fulafel 4mo ago
Both of these (copy fail and dirtyfrag) exploit obscure socket address families. Are these filtered by commonly used seccomp profiles in eg docker (assuming seccomp can express it)?
- YZF 4mo ago
  At least in the k8s setup I looked at the dirtyfrag were filtered (by default). "XFRM SA registration requires CAP_NET_ADMIN".
  - fulafel 4mo ago
    Right, so it blocked the first part of the chain. Which normally uses unprivilgeed network namespace to dp net admin inside that. I had been thinking of a RxRPC AF block for the second part of the chain which seems rarer. Systemd seems to have this setting for units since 2011: > The setting RestrictAddressFamilies aims to restrict what socket address families can be used. When using it, the default is that it is used as an allow-list and define what address families can be used. > Example > A common combination might look like this. [Service] SystemCallArchitectures=native RestrictAddressFamilies=AF_INET AF_INET6 AF_UNIX
fulafel 4mo ago
RxRPC is apparently an AFS (Andrew File System) thing.
nicman23 4mo ago
well at least they are not commonly loaded - in like 12 machines i have
RandomGerm4n 4mo ago
Perhaps we should consider designing distributions to be more tailored to specific purposes. Since no one needs the affected module on a desktop computer, distributions designed for that purpose should no longer include it by default. If this approach were consistently followed, significantly fewer systems would be vulnerable to such exploits. For most users a system with a kernel as minimalistic as the Android GKI kernel combined with sensible SELinux policies, would likely be sufficient.
- fulafel 4mo ago
  Both of the modules are (also) for desktop/workstation use. Though AFS could probably be retired generally.
drmpeg 4mo ago
Looks like the esp4 and esp6 fixes have been pushed for 7.0, 6.18, 6.12 and 6.6 kernels. https://lore.kernel.org/lkml/2026050851-iron-hurdle-6421@gregkh/ https://lore.kernel.org/lkml/2026050851-iron-hurdle-6421@gre... https://lore.kernel.org/lkml/2026050843-unplowed-spinster-cfa8@gregkh/ https://lore.kernel.org/lkml/2026050843-unplowed-spinster-cf... https://lore.kernel.org/lkml/2026050832-remold-faceless-bed0@gregkh/ https://lore.kernel.org/lkml/2026050832-remold-faceless-bed0... https://lore.kernel.org/lkml/2026050825-heaving-spender-13a8@gregkh/ https://lore.kernel.org/lkml/2026050825-heaving-spender-13a8...
- eqvinox 4mo ago
  And again it's band-aiding the problem. Can authencesn not be fixed or what?
  - wolttam 4mo ago
    Maybe write to the LKML if you have some privy information?
    - eqvinox 4mo ago
      I don't have enough hubris to assume I know things the people on LKML (or actually netdev in this case) don't. If anything, I might unicast a mail to Steffen.
titanomachy 4mo ago
I'm not a security expert, but I'm responsible for some (relatively low-stakes) production systems. It sounds like these two most recent exploits depend on unprivileged user namespaces, and that in fact a high percentage of LPE exploits need this feature. I use rootless containers on a couple of systems (like my dev machine server), but on most of my systems I don't, so it sounds like disabling that would be a good step to hardening my systems against future exploits. To the security experts: are there any other straightforward configuration changes with such broad-reaching improvement in security posture? Any well-written guides on this subject, something like "top kernel modules to consider disabling if you don't need them"? I'm not talking about the obvious stuff like "disable password SSH", I'm specifically looking for steps that are statistically likely to prevent as-yet-unknown privilege escalation attacks.
- staticassertion 4mo ago
  You don't need unprivileged user namespaces for this one if you're in a position to get the target kernel module loaded. But yeah, user namespaces are basically the single most significant privesc path in the kernel, maybe io-uring is second. Disabling both (or very carefully deciding what can use them) is one of the best ways to reduce your attack surface. I don't have any guides but you can determine which kernel modules are already loaded in your system and then just compile those in and block module loading. Otherwise, shove everything into a container, ideally gvisor, and you've reduced attack surface by a large chunk again via seccomp.
bytejanitor 4mo ago
Is there a CVE identifier available for this yet?
Luker88 4mo ago
I can't make it work on nixos. Kernel 7.0.1 I tried fixing the paths and even linking `/bin/bash` to the nix /run/current-system/sw/bin/bash /etc/passwd is unmodified. Can anyone else try? CopyFail1 did not work because `su` is only executable, not readable, CopyFail2 worked only partially (changes /etc/passwd but the user is not passwordless)
BoldBrook418 4mo ago
[dead]
biennvops 4mo ago
[dead]
snvzz 4mo ago
There's, in practice, unlimited such bugs in the megabytes of kernel object code. Monolithic UNIX-like kernels are a bankrupt design. Only third generation microkernels like seL4[0] make sense in the present world. All effort put elsewhere is wasted outright. 0. https://sel4.systems/ https://sel4.systems/
danborn26 4mo ago
The fragmentation logic in the networking stack has been a recurring source of bugs for years. It is surprising how these edge cases keep surviving multiple security audits.
- kro 4mo ago
  It's scary to think that some day it will be more than a local attack vector. I don't want to imagine the fallout from a remote rce via tcp/ip.
nxobject 4mo ago
I know this was a thing re: Copy Fail, but... ...LPE = "local privilege escalation", for everyone not directly involved in the security.
m3nu 4mo ago
Ansible playbook to mitigate and verify: https://gist.github.com/m3nu/d85533bbf342edd3a9426711409a1b9a https://gist.github.com/m3nu/d85533bbf342edd3a9426711409a1b9...
WindyBolt907 4mo ago
[dead]
CalmBirch127 4mo ago
[dead]
Steinmark 4mo ago
[dead]
WindyBolt907 4mo ago
[dead]
QuietLedge375 4mo ago
[dead]

819 points by flipped 4mo ago

Where is the famous Linux is so much secure than Windows? I would like to see the same hate comments about Linux than the ones we would see if it was a Windows vulnerability...

baggy_trough 4mo ago

Disclosure Timeline 2026-04-29: Submitted detailed information about the rxrpc vulnerability and a weaponized exploit that achieves root privileges on Ubuntu to security@kernel.org. 2026-04-29: Submitted the patch for the rxrpc vulnerability to the netdev mailing list. Information about this issue was published publicly. 2026-05-07: Submitted detailed information about the vulnerability and the exploit to the linux-distros mailing list. The embargo was set to 5 days, with an agreement that if a third party publishes the exploit on the internet during the embargo period, the Dirty Frag exploit would be published publicly. 2026-05-07: Detailed information and the exploit for the esp vulnerability were published publicly by an unrelated third party, breaking the embargo. 2026-05-07: After obtaining agreement from distribution maintainers to fully disclose Dirty Frag, the entire Dirty Frag document was published.

flumpcakes 4mo ago
7 days from disclosure to publishing a how-to guide to get root to the entire planet doesn't scream "responsible" disclosure to me.
- deleted 4mo ago
  [deleted]
- bawolff 4mo ago
  Its not the reporter's fault that other people broke the embargo.
  - progval 4mo ago
    They don't have to publish a working exploit as soon as the embargo is broken, though.
    - mike_d 4mo ago
      Why not? There has already been a working exploit floating around, at least now it comes from an authoritative source.
    - john_strinlai 4mo ago
      anyone who will use the exploit maliciously will immediately and trivially be able to create a working exploit.
    - throw0101c 4mo ago
      Perhaps, but if the exploit code is published folks can double-check that they implemented the mitigations properly. If there's no PoC, how can you really be sure?
    - staticassertion 4mo ago
      An exploit was already published.
    - j16sdiz 4mo ago
      The third party posted an exploit.
- firer 4mo ago
  My immediate reaction was the same. But this is very similar to Copy Fail, and I'm assuming there was an assumption that others might also discover this soon as well. Hence the urgency. At least that's my charitable interpretation.
- lofaszvanitt 4mo ago
  WTF cares? Publish them without disclosure is the true way, otherwise noone would care about security and your data.

john_strinlai 4mo ago

"Because the embargo has now been broken, no patches or CVEs exist for these vulnerabilities." link: https://github.com/V4bel/dirtyfrag https://github.com/V4bel/dirtyfrag detailed writeup: https://github.com/V4bel/dirtyfrag/blob/master/assets/write-up.md https://github.com/V4bel/dirtyfrag/blob/master/assets/write-... importantly: "Copy Fail was the motivation for starting this research. In particular, xfrm-ESP Page-Cache Write in the Dirty Frag vulnerability chain shares the same sink as Copy Fail. However, it is triggered regardless of whether the algif_aead module is available. In other words, even on systems where the publicly known Copy Fail mitigation (algif_aead blacklist) is applied, your Linux is still vulnerable to Dirty Frag." mitigation (i have not tested or verified!): "Because the responsible disclosure schedule and the embargo have been broken, no patch exists for any distribution. Use the following command to remove the modules in which the vulnerabilities occur." sh -c "printf 'install esp4 /bin/false\ninstall esp6 /bin/false\ninstall rxrpc /bin/false\n' > /etc/modprobe.d/dirtyfrag.conf; rmmod esp4 esp6 rxrpc 2>/dev/null; true" conversation around the mitigation suggests you need a reboot or run this after the above on already-exploited machines: sudo echo 3 > /prox/sys/vm/drop_caches

progval 4mo ago
"sudo" in "sudo echo 3 > /prox/sys/vm/drop_caches" does not do anything because only runs echo, not the write. And if a machine is already exploited, it's too late to do just that. You need to rebuild the whole disk image because anything on it could be compromised.
- john_strinlai 4mo ago
  >And if a machine is already exploited, it's too late to do just that. You need to rebuild the whole disk image because anything on it could be compromised. this is more targeted at the people who run the PoC to see if their machine is vulnerable. just transcribing some relevant stuff from https://github.com/V4bel/dirtyfrag/issues/1 https://github.com/V4bel/dirtyfrag/issues/1 so that people visiting this thread dont need to poke around a bunch of different places.
dundarious 4mo ago

Tiberium 4mo ago

Do you think with modern LLMs in a few years projects like Linux will have all those low-hanging security bugs fixed? Are we witnessing a transition period, or will nothing change?

staticassertion 4mo ago
New vulns are introduced to Linux every day. Fuzzers trigger every single day on Linux. No, nothing will improve here from AI.
- Muromec 4mo ago
  There is a finite number of bugs and betters tools that find them mean there is less bugs in the code.
  - staticassertion 4mo ago
    We already find bugs constantly in Linux and they go unaddressed, no one even keeps up with syzkaller reports lol AI is neat because it's higher signal but yeah no, we're not getting anywhere close to "safe linux", AI or not.
    - Muromec 4mo ago
      I want to believe, okay
- alex_duf 4mo ago
  there's an argument to be made that new code will be inspected before being merged and therefore the classes of bugs an LLM is likely to find will not be merged until it's fixed.
deleted 4mo ago
[deleted]
spartanatreyu 4mo ago
LLMs don't matter, linux's codebase has been growing much faster than it can be secured so this is all inevitable. Transitioning components to rust eliminates certain categories of bugs leaving the rest of the bugs to be dealt with. We'd likely end up needing another language with stronger type and effect systems to eliminate more categories of bugs. Probably something which enforces linear types, capabilities, units of measure types, and effects. And you'd have to update linux itself to switch to capabilities.

miduil 4mo ago

This again does not work under Android, at least in termux compiled with clang/gcc.

ronsor 4mo ago
Android has a lot of hardening and sandboxing that desktop Linux doesn't (and won't for UX reasons).
- miduil 4mo ago
  Yes, it demonstrates that it's possible to harden well - at least for some cases. It appears depending on the environment hardened kernel / runtime environments are pretty much possible to have safeguards working today already.
- deleted 4mo ago
  [deleted]
- __float 4mo ago
  > desktop Linux doesn't (and won't for UX reasons) Can you elaborate?
  - danudey 4mo ago
    Not sure what specifically they're referring to, but Android (and iOS) add a lot of sandboxing to ensure that each application can only access its own files, can't access hardware willy-nilly (bluetooth, scanning wifi, etc), can only link against certain libraries, etc. Imagine if Linux only let you run stuff from Flatpak, and if stuff didn't work in Flatpak then too bad for you. Most Linux users would hate it and it would be a mess a lot of the time, so, for user experience (UX) reasons, they don't do it. Android can get away with it because that's been the app paradigm for decades now.
  - akdev1l 4mo ago
    A very comprehensive SELinux deployment for one. SELinux will stop any process in android from loading kernel modules, that’s not allowed. The android permission model as a whole is ultimately backed by SELinux.

BadBadJellyBean 4mo ago

Well this is getting tiresome. I wish there was a less stressful way to get fixes for such bugs. But the cat is out of the bag now. Not criticizing whoever found the bug, of course.

deleted 4mo ago

[deleted]

unethical_ban 4mo ago

Here's a general question, are these vulnerabilities hitting Linux more than BSDs due to hit being a larger target or because its architecture is less secure by design?

staticassertion 4mo ago
Larger target.
- golem14 4mo ago
  in many ways: - more people are using it (assuming macos is in its own bucket perhaps) - bigger surface areas (esp NetBSD has in my limited understanding just less stuff that can go boom) - more churn, ie more new stuff than can be buggy released more often. Of course, because of that, more eyes are on Linux, so I'm not sure where that security tradeoff is.
ahartmetz 4mo ago
AFAIU, Linux and the BSDs have basically the same architecture - the BSDs just value secure and simple, understandable code more highly than Linux vs features and performance.
- angry_octet 4mo ago
  This is really not a correct statement beyond the fact that both are a type of Unix.
  - cluckindan 4mo ago
    Linux is not Unix: it is not derived from AT&T Unix.
    - ahartmetz 4mo ago
      Linux 2.2 or 2.4 or so (possibly only Suse Linux) even had a kernel startup message "Unix compliance testing by UNIFIX" or something, back when Unix was considered more prestigious than Linux. It is / was by some official definition "a Unix", though not "UNIX the trademark by AT&T".

int0x29 4mo ago

I'm curious what broke the embargo. Did it leak or did a third party find it independently?

john_strinlai 4mo ago
it was published publicly by an unrelated third party
- jacobgkau 4mo ago
  They're asking the nature of the third party's discovery/publishing. Someone on the inside who decided to leak it anonymously? Someone else who was able to access some private communication they shouldn't have been able to see? Or a third party who happened to discover the same vulnerability (which seems less unlikely than normal since this is so similar to Copy Fail), but didn't follow disclosure procedures?
  - staticassertion 4mo ago
    The commit for the fix was public. Someone noticed. An exploit was published.
    - ahartmetz 4mo ago
      I think I read on the bug's website that "No fix has been released". I understood that as there is no public fix, but maybe it only means it's not in a tagged version of the kernel and no hotfixed distro kernels have been released?
      - danudey 4mo ago
        The patch was posted to the kernel mailing list; someone saw the e-mail, read the patch, figured it out, and published an exploit very soon after.
      - tkel 4mo ago

oncallthrow 4mo ago

can this also be used to obtain container escape ?

synack 4mo ago
If your container has setuid binaries and these modules are loaded, yes.
- lights0123 4mo ago
  With the exploits published as-is, you'll only get root inside the container: there's no explicit namespace break, and calling setuid() in a container just gives you root in the container. However, it can be used to modify files that are passed into the container (e.g. Docker run -v), or files that are shared with other containers (e.g. other Docker containers sharing the same layers). kube-proxy with Kubernetes happens to share a trusted binary with containers by default, which is how it can be exploited: https://github.com/Percivalll/Copy-Fail-CVE-2026-31431-Kubernetes-PoC https://github.com/Percivalll/Copy-Fail-CVE-2026-31431-Kuber...
- miduil 4mo ago
  It's poisoning the filesystem cache, if you don't have a setuid binary handy you just poison anything else that gets executed by the host.
- awoimbee 4mo ago
  And your containers need to have specific capabilities enabled, which aren't by default on kubernetes and podman.
  - friedr12 4mo ago
    [dead]
- aaronmdjones 4mo ago
  You don't need any setuid binaries. You could just as easily use the vulnerability to add a job to crontab(5) that causes the cron daemon to run whatever you want as root.

firer 4mo ago

This is very similar in root cause and exploitation to Copy Fail. Which illustrates pretty well something that's lost when relying heavily on LLMs to do work for you: exploration. I find that doing vulnerability research using AI really hinders my creativity. When your workflow consists of asking questions and getting answers immediately, you don't get to see what's nearby. It's like a genie - you get exactly what you asked for and nothing more. The researcher who discovered Copy Fail relied heavily on AI after noticing something fishy. If he had to manually wade through lots of code by himself, he would have many more chances to spot these twin bugs. At the same time, I'm pretty sure that by using slightly less directed prompting, a frontier LLM would found these bugs for him too. It's a very unusual case of negative synergy, where working together hurt performance.

eqvinox 4mo ago
No, unless I'm misreading it it's the *same* root cause: high 32 bits of Extended ESN in IPsec == authencesn module/cipher mode. The wrong thing got fixed for copy.fail, because people jumped to blame AF_ALG. [ed.: yes it's the same authencesn issue. https://github.com/V4bel/dirtyfrag/blob/892d9a31d391b7f0fccb333855f6289507186748/exp.c#L210 https://github.com/V4bel/dirtyfrag/blob/892d9a31d391b7f0fccb... it doesn't say authencesn in the code, only in a comment, but nonetheless, same issue.] [ed.2: the RxRPC issue is separate, this is about the ESP one]
- firer 4mo ago
  There are two vulnerabilities here. The RxRPC one is definitely a different root cause (although caused by a very similar mistake). For the ESP one it's a bit harder to tell. I don't think the wrong thing was fixed, just that there was a very similar bug in almost the same spot. Could be wrong about that though.
  - eqvinox 4mo ago
    (you probably wrote this while I was editing my post.) It's absolutely the same issue in authencesn/ESP. There's another one in RxRPC that is AIUI completely unrelated.

normie3000 4mo ago

So umm... should I rush home and turn off all my computers?

arcfour 4mo ago
Are they already vulnerable to RCE as an unprivileged user? Hopefully not. An LPE only allows an attacker who can already execute code on the system to become root. So, bad, yes, but it doesn't mean you are immediately pwned.
- hughw 4mo ago
  Should I rush to Lambda or ECS and turn off all my containers sharing a host with who the hell knows?
  - tkel 4mo ago
    Like others have said, this will get you root inside the container. It isn't a container escape. File/volume mounts shared across containers would be vulnerable.
  - arcfour 4mo ago
    Firecracker is extremely hardened, so I wouldn't worry about Lambda. As for ECS, getting root doesn't necessarily mean you have a container escape. I think you could escape containers with this exploit, but you would need a different payload than what's published. I could be wrong though. I would assume AWS is pretty on the ball when it comes to handling stuff like this if they didn't have other defenses or mitigations in place already.
  - PhilipRoman 4mo ago
    AFAIK Lambda and everything else will use micro-VMs. No serious company would use a shared kernel design for workloads in different security contexts. (Personally I wouldn't even use the same hardware host, but sometimes sacrifices have to be made)
- account42 4mo ago

eqvinox 4mo ago

And I ask again: why the f*ck is algif_aead getting all the flak for copy.fail? It's authencesn being stupid. authencesn didn't get fixed. Now we got the results of that, turns out you can access the same (I believe) out of bounds write through plain network sockets. I wish I thought of that, but I didn't. [ed.: I'm referring to the through-ESP issue. The RxRPC one is AIUI completely unrelated.]

xxpor 4mo ago

Linux is a single user system and should be treated as such. Run your services as root. Don't rely on unix user primitives for security.

wolttam 4mo ago
Running as root opens you up to a class of vulnerabilities (denial of service, mainly) that you can avoid by not running as root. That said, running every process in its own micro VM is looking more attractive by the minute.
- xxpor 4mo ago
  Half the point is that you should always assume that there exists a complete LPE bug. But yes, micro VMs are a great idea!
amarant 4mo ago
Everything in this comment is wrong.
- xxpor 4mo ago
  Technically yes. Practically, I disagree.
  - eqvinox 4mo ago
    The part where you run everything as root is particularly stupid. But yes, user isolation has been weakened quite a bit.
256_ 4mo ago
I agree with the general sentiment. I treat anything running arbitrary machine code as if it has full access to a machine. I don't know where you get "run your services as root" from that, though. The principle of least privilege doesn't just apply to running malicious code, but running buggy code whose attack surface is exposed to evil-doers.
4mo ago

zepearl 4mo ago

So if I understand correctly 3 modules are involved: - esp4 (kernel config "CONFIG_AF_RXRPC") - esp6 (kernel config "CONFIG_INET_ESP") - rxrpc (kernel config "CONFIG_INET6_ESP") Is this correct?

eqvinox 4mo ago
You mixed up the names vs. config options but yes killing those 3 options should make you "safe". No warranty.
- zepearl 4mo ago
  damn you're right, thx

deleted 4mo ago

[deleted]

ftheplan9 4mo ago

[flagged]

john_strinlai 4mo ago
>2026-05-07: After obtaining agreement from distribution maintainers to fully disclose Dirty Frag, the entire Dirty Frag document was published. you think the reporters and the distribution maintainers colluded to... get 5 minutes of attention? that would be exceptionally stupid of the distribution maintainers and destroy all trust.

arian_ 4mo ago

Every time someone finds a universal Linux privilege escalation, somewhere a sysadmin whispers 'this is why we don't run as root' while nervously checking if their containers are actually isolated.

oncallthrow 4mo ago
> this is why we don't run as root The entire point is that you can escalate to root
minimaltom 4mo ago
This attack class lets you escalate from any user to UID 0. Not running as root won't save you, in fact, this attack is for those processes not running as root. However, if you are in a user namespace where UID 0 doesn't map to system-wide capabilities, and you dont share page cache for the setuid binaries on the system, this attack doesn't lead to LPE.
- delamon 4mo ago
  setuid binaries are not the only way to get root. E.g. one can change /etc/crontab or /etc/passwd. Or add trojan to /bin/ls and wait until admin type 'ls'
  - quantummagic 4mo ago
    It's not always as easy as you imply. All the attack vectors you mentioned, require root on the host, before you can make the change or install the trojan.
    - delamon 4mo ago
      The attack gives you ability to overwrite any cached page. So you don't need to be root to "edit" /etc/passwd.
      - quantummagic 4mo ago

KamiNuvini 4mo ago

Does anyone know whether Debian is vulnerable? I tried the exploit on a Debian 12+Debian 13 machine but wasn't able to reproduce it myself.

cholmon 4mo ago
I just tried the exploit on a fresh Debian 13 droplet on digitalocean and it worked.
thaniri 4mo ago
I was able to reproduce this issue on kernel 6.12.57+deb13-amd64 running Debian 13 (Trixie), but unable to reproduce it on kernel 6.1.0-42-amd64 running Debian 12 (Bookworm). For anyone not on the security stream of Debian packages for Bookworm, kernel version 6.1.0-42-amd64 is actually immune to copy.fail. Surprising that it looks to be immune to dirtyfrag. If you haven't already patched on the security stream, you can choose any kernel version that kept commit 2b8bbc64b5c2. I am thinking that the same commit might accidentally be keeping certain Debian 12 kernel versions safe from dirtyfrag as well.
louwrentius 4mo ago
I tested on a fully up-to-date Debian 13 and the exploit works. The mitigation also works / confirmed.
deleted 4mo ago
[deleted]
Existing4190 4mo ago
https://security-tracker.debian.org/tracker/CVE-2026-43500 https://security-tracker.debian.org/tracker/CVE-2026-43500 https://security-tracker.debian.org/tracker/CVE-2026-43284 https://security-tracker.debian.org/tracker/CVE-2026-43284
baggy_trough 4mo ago
Debian 13 is offering linux-image-6.12.86+deb13 now.

chromacity 4mo ago

If this indeed works on all major distributions, I just continue to be amazed by how irresponsible the maintainers are. We're talking about optional kernel functionality that's presumably useful to something like <0.1% of their userbase, but is enabled by default?... why? This feels like the practice of Linux distros back in 1999 when they'd ship default installs with dozens of network services exposed to the internet. Except it's not 1999 anymore.

TacticalCoder 4mo ago
> ... but is enabled by default?... why? We could also wonder why XZ was linked to SSH... But only on systemd-enabled distros (which is a lot of them). Just... Why? And then make sure to call to incompetence, instead of malice and say non-sense like "Sure, it only factually affects systemd distros, but this is totally not related to systemd". All I saw though was a systemd backdoor (sorry, exploit). Now regarding copy.fail that just happened: not all maintainers are irresponsible. And some have, rightfully, bragged that the security measures they preemptively took in their distros made them non vulnerable. But yup I agree it's madness. Just why. And Ubuntu is a really bad offender: it's as if they did a "yes | .." pipe to configure every single modules as an include directly in the kernel. "We take security seriously, look we've got the IPsec backdoor (sorry, exploit) modules directly in the kernel". "There's 'sec' in 'IPsec', so we're backdoored (sorry, secure)".
- chuckadams 4mo ago
  xz was not directly linked to ssh, and systemd itself was not providing the backdoor. The weakness is embedded into the architecture of glibc (which has spread to other systems like FreeBSD as well): https://github.com/robertdfrench/ifuncd-up https://github.com/robertdfrench/ifuncd-up
  - TacticalCoder 4mo ago
    Sure, but distros not using systemd were not affected.

deleted 4mo ago

[deleted]

eqvinox 4mo ago

If you don't need it (rootless containers), you can disable unprivileged userns to block these two: echo 1 | sudo tee /proc/sys/kernel/apparmor_restrict_unprivileged_userns May also break sandboxes (e.g. browser) though.

deleted 4mo ago

[deleted]

acedTrex 4mo ago

Here we go again

jcims 4mo ago

Tested Amazon Linux 2023 and it doesn't appear to be vulnerable in the default configuration. Would be interested if anyone finds anything different.

CalmBirch127 4mo ago

[dead]

HollowRidge427 4mo ago

[dead]

deleted 4mo ago

[deleted]

deleted 4mo ago

[deleted]

teaearlgraycold 4mo ago

Anyone here with experience providing multi-tenant Linux systems (CI and the like), do providers usually disable kernel modules they don’t need to eliminate attack surface? Every time one of these comes out I wonder if I should be rotating every key in my GitHub CI or PaaS host. So far I haven’t seen any reports from the providers I use that they were pwned by any of these exploits.

TheDong 4mo ago
A lot of these multi-tenant CI systems actually run everything in microVMs even if they present it to you as a container. At this point, a microvm can be booted in ~200ms so you don't even have to keep a warm pool, you can just launch em on demand. GitHub CI (actions) uses virtual machines.

ftheplan9 4mo ago

[flagged]

kinow 4mo ago

Just got an email from one HPC I have access in Germany. I guess all HPCs ans services like GH Actions are going to be offline for a bit. I think last time was on a Friday too, so it might be another Friday to organize emails, files, rotate backup/passwords...

hughw 4mo ago

Ran as a fresh new default user in a ubuntu:latest container git clone https://github.com/V4bel/dirtyfrag.git && cd dirtyfrag && gcc -O0 -Wall -o exp exp.c -lutil && ./exp Result: dirtyfrag: failed (rc=3) Good news!

Havoc 4mo ago
Wouldn't count on container being a reliable testing platform for this. Loads of stuff - legitimate or otherwise - fails in containers
stsewd 4mo ago
I got the same running it inside a container, but got a shell when running it directly in the host. This only shows that the exploit doesn't work inside a container. So, containers aren't vulnerable, or the script needs some adjustments to make it work in containers. Since copy fail can be used to escape containers (https://github.com/Percivalll/Copy-Fail-CVE-2026-31431-Kubernetes-PoC https://github.com/Percivalll/Copy-Fail-CVE-2026-31431-Kuber...), I'm guessing the exploit needs some changes only.
- cyphar 4mo ago
  The repo you linked works by replacing files that are being used by other privileged containers on the same system. That works for the Kubernetes case (I'm a little surprised they don't use static binaries for their own privileged containers, seems a little dangerous to share any kind of data with untrusted tenants even if it's read-only) but not standalone containers. However, there is a much an easier way of doing a breakout -- you can corrupt the host runc binary in a way analogous to CVE-2019-5736. The next time a container is spawned, the host runc binary will get run as as root and that's that. Ironically, the first version of the protection against this attack I wrote also protected against page cache poisoning (by making a temporary copy of the runc binary during container setup in a sealed memfd and re-execing that) but the runtime cost of copying a 10MB binary at container startup was seen as too expensive by some users[1] so we ended up with a setup that shares the same page cache. I also distinctly remember arguing at the time that something like Dirty Cow could always happen in the future, and the memfd approach was better for that reason -- maybe I should've stuck to my guns more... :/ In practice the solution for containers is to update your seccomp policy to block the vulnerable syscall. [1]: https://github.com/opencontainers/runc/issues/1980 https://github.com/opencontainers/runc/issues/1980

x4132 4mo ago

this is why you don't contact distro mailing list. responsible disclosure is dead.

zbentley 4mo ago
At present it looks to me like the embargo was broken by someone identifying the patch as fixing a vulnerability, not someone leaking the mailing list. More information may come out, or I might be missing something, but assuming that the above is accurate, this isn't a problem with responsible disclosure or mailing list opsec; it's a problem with the nature of open source. Right? Or are folks seriously proposing that the patch/mitigations should have been circulated to distro maintainers privately before going to mainline?
- collinmanderson 4mo ago
  > Or are folks seriously proposing that the patch/mitigations should have been circulated to distro maintainers privately before going to mainline? I always assumed that distro maintainers got early access to patches before going mainline but maybe that’s not true?
  - deleted 4mo ago
    [deleted]

7373737373 4mo ago

Tanenbaum was right

TZubiri 4mo ago
Go on...
- 7373737373 4mo ago
  https://youtube.com/watch?v=oS4UWgHtRDw https://youtube.com/watch?v=oS4UWgHtRDw

Retr0id 4mo ago

Testing the rxrpc vuln on aarch64, I get a kernel data abort, which is interesting. Not looked into the root cause yet!

Retr0id 4mo ago
Huh why is this getting downvoted?

thom 4mo ago

After all these years, we finally have enough eyeballs that all bugs are shallow, and it kinda sucks. How many times a week am I going to be updating my kernel from now on?

brcmthrowaway 4mo ago
So you think someone is going to break into your house, find your default credentials somehow and get root access?
- sureglymop 4mo ago
  With physical access, root access is as simple as setting init=/bin/bash in the kernel parameters from a bootloader. No need for credentials or anything.
  - anygivnthursday 4mo ago
    Secure boot and disk enryption are not that unusual nowdays
    - Asraelite 4mo ago
      Secure boot doesn't provide security, just control for device manufacturers. Physical access always means the device is pwned. You can install a keylogger or something similar.
      - qrobit 4mo ago
        Secure boot ensures the image you boot was not tampered with. You can't install keylogger without tampering with the image. If you wanted to install physical keylogger, you would need to open the device up, and at least my laptop provides detection of bottom cover removal, meaning the system will ask you for a bios password if the laptop was opened up.
- thom 4mo ago

deleted 4mo ago

[deleted]

caned 4mo ago

The enforcement of read-only protection for pagecache pages (and the scatterlists and or other structures they point to) seems to be diffuse and incredibly fragile.

baggy_trough 4mo ago

From the 3rd party discloser: https://openwall.com/lists/oss-security/2026/05/07/12 https://openwall.com/lists/oss-security/2026/05/07/12

deleted 4mo ago

[deleted]

cynicalsecurity 4mo ago

Imagine how many undiscovered bugs and exploits exist in Windows.

tap-snap-or-nap 4mo ago
Noone has the time given how many windows bugs are already open and active long term.

netheril96 4mo ago

We need an easy way to ensure that only kernel modules in an whitelist can load. I’m tired of blacklisting modules I never need.

lyu07282 4mo ago

Two distro independent LPEs in such a short time, if only all Linux software could be this portable.

infrapilot 4mo ago

[flagged]

staticassertion 4mo ago
> The old “quiet patch before disclosure” model may simply not work anymore in the LLM era. It never did. Trawling the Linux commit history is a tried and true method for finding n-days.

mikeweiss 4mo ago

Considering AWS just released patches for Copy Fail for Amazon Linux and Bottlerocket only yesterday.... I imagine it will over a week before we see patches for this. This is especially important to fix on Kubernetes nodes...does anyone have any recommendations for mitigating this issue before a patch is released?

QuietLedge375 4mo ago

[dead]

deleted 4mo ago

[deleted]

fulafel 4mo ago

Both of these (copy fail and dirtyfrag) exploit obscure socket address families. Are these filtered by commonly used seccomp profiles in eg docker (assuming seccomp can express it)?

YZF 4mo ago
At least in the k8s setup I looked at the dirtyfrag were filtered (by default). "XFRM SA registration requires CAP_NET_ADMIN".
- fulafel 4mo ago
  Right, so it blocked the first part of the chain. Which normally uses unprivilgeed network namespace to dp net admin inside that. I had been thinking of a RxRPC AF block for the second part of the chain which seems rarer. Systemd seems to have this setting for units since 2011: > The setting RestrictAddressFamilies aims to restrict what socket address families can be used. When using it, the default is that it is used as an allow-list and define what address families can be used. > Example > A common combination might look like this. [Service] SystemCallArchitectures=native RestrictAddressFamilies=AF_INET AF_INET6 AF_UNIX

fulafel 4mo ago

RxRPC is apparently an AFS (Andrew File System) thing.

nicman23 4mo ago

well at least they are not commonly loaded - in like 12 machines i have

RandomGerm4n 4mo ago

Perhaps we should consider designing distributions to be more tailored to specific purposes. Since no one needs the affected module on a desktop computer, distributions designed for that purpose should no longer include it by default. If this approach were consistently followed, significantly fewer systems would be vulnerable to such exploits. For most users a system with a kernel as minimalistic as the Android GKI kernel combined with sensible SELinux policies, would likely be sufficient.

fulafel 4mo ago
Both of the modules are (also) for desktop/workstation use. Though AFS could probably be retired generally.

drmpeg 4mo ago

Looks like the esp4 and esp6 fixes have been pushed for 7.0, 6.18, 6.12 and 6.6 kernels. https://lore.kernel.org/lkml/2026050851-iron-hurdle-6421@gregkh/ https://lore.kernel.org/lkml/2026050851-iron-hurdle-6421@gre... https://lore.kernel.org/lkml/2026050843-unplowed-spinster-cfa8@gregkh/ https://lore.kernel.org/lkml/2026050843-unplowed-spinster-cf... https://lore.kernel.org/lkml/2026050832-remold-faceless-bed0@gregkh/ https://lore.kernel.org/lkml/2026050832-remold-faceless-bed0... https://lore.kernel.org/lkml/2026050825-heaving-spender-13a8@gregkh/ https://lore.kernel.org/lkml/2026050825-heaving-spender-13a8...

eqvinox 4mo ago
And again it's band-aiding the problem. Can authencesn not be fixed or what?
- wolttam 4mo ago
  Maybe write to the LKML if you have some privy information?
  - eqvinox 4mo ago
    I don't have enough hubris to assume I know things the people on LKML (or actually netdev in this case) don't. If anything, I might unicast a mail to Steffen.

titanomachy 4mo ago

I'm not a security expert, but I'm responsible for some (relatively low-stakes) production systems. It sounds like these two most recent exploits depend on unprivileged user namespaces, and that in fact a high percentage of LPE exploits need this feature. I use rootless containers on a couple of systems (like my dev machine server), but on most of my systems I don't, so it sounds like disabling that would be a good step to hardening my systems against future exploits. To the security experts: are there any other straightforward configuration changes with such broad-reaching improvement in security posture? Any well-written guides on this subject, something like "top kernel modules to consider disabling if you don't need them"? I'm not talking about the obvious stuff like "disable password SSH", I'm specifically looking for steps that are statistically likely to prevent as-yet-unknown privilege escalation attacks.

staticassertion 4mo ago
You don't need unprivileged user namespaces for this one if you're in a position to get the target kernel module loaded. But yeah, user namespaces are basically the single most significant privesc path in the kernel, maybe io-uring is second. Disabling both (or very carefully deciding what can use them) is one of the best ways to reduce your attack surface. I don't have any guides but you can determine which kernel modules are already loaded in your system and then just compile those in and block module loading. Otherwise, shove everything into a container, ideally gvisor, and you've reduced attack surface by a large chunk again via seccomp.

bytejanitor 4mo ago

Is there a CVE identifier available for this yet?

Luker88 4mo ago

I can't make it work on nixos. Kernel 7.0.1 I tried fixing the paths and even linking `/bin/bash` to the nix /run/current-system/sw/bin/bash /etc/passwd is unmodified. Can anyone else try? CopyFail1 did not work because `su` is only executable, not readable, CopyFail2 worked only partially (changes /etc/passwd but the user is not passwordless)

BoldBrook418 4mo ago

[dead]

biennvops 4mo ago

[dead]

snvzz 4mo ago

There's, in practice, unlimited such bugs in the megabytes of kernel object code. Monolithic UNIX-like kernels are a bankrupt design. Only third generation microkernels like seL4[0] make sense in the present world. All effort put elsewhere is wasted outright. 0. https://sel4.systems/ https://sel4.systems/

danborn26 4mo ago

The fragmentation logic in the networking stack has been a recurring source of bugs for years. It is surprising how these edge cases keep surviving multiple security audits.

kro 4mo ago
It's scary to think that some day it will be more than a local attack vector. I don't want to imagine the fallout from a remote rce via tcp/ip.

nxobject 4mo ago

I know this was a thing re: Copy Fail, but... ...LPE = "local privilege escalation", for everyone not directly involved in the security.

m3nu 4mo ago

Ansible playbook to mitigate and verify: https://gist.github.com/m3nu/d85533bbf342edd3a9426711409a1b9a https://gist.github.com/m3nu/d85533bbf342edd3a9426711409a1b9...

WindyBolt907 4mo ago

[dead]

CalmBirch127 4mo ago

[dead]

Steinmark 4mo ago

[dead]

WindyBolt907 4mo ago

[dead]

QuietLedge375 4mo ago

[dead]