Devastating 'Dirty Frag' exploit leaks out, gives immediate root access on most Linux machines since 2017, no patches available, no warning given — Copy Fail-like vulnerability had its embargo broken

News
By published

A great disturbance in the cyberspace, as if millions of sysadmins suddenly cried out in terror.

Lock being picked
(Image credit: Getty Images)

Here's a question for the systems administrators in the crowd: what's better than one instant-root™️Linux vulnerability that affects most every system since 2017? Two of them, of course. Today's bag of bad news comes by way of the Dirty Frag vulnerability, which uses a mechanism similar to the Copy Fail exploit that's currently setting the Linux server world on fire. This vulnerability affects nearly every Linux install since 2017, and no advance warning was given, so there is no patch available. This appears to be due to a broken embargo that revealed the vulerability before preparations were made.

As a refresher, any local user can instantly get root (administrator) access on an affected box, just by running a small program. The attack does not depend on specific system conditions or timing, as it's a straightforward logic bug. Most every popular Linux distribution since 2017 is affected, including but not limited to current versions of Ubuntu (24 and 26), Arch, RHEL, OpenSUSE, CentOS Stream, Fedora, and Alma. We even tested WSL2 ourselves and sure enough, "root" was the word.

Latest Videos From
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"

The reason why Dirty Frag is catching everyone flat-footed is because although the vulnerability was reported to the Linux kernel team in April 30, an "unrelated third party" broke the embargo for the reveal. The website offers no more detail, but our best theory is that it means the exploit is already in use by malicious actors, prompting the embargo breakage. If you want to test your boxen, you can use:

git clone https://github.com/V4bel/dirtyfrag.git && cd dirtyfrag && gcc -O0 -Wall -o exp exp.c -lutil && ./exp

As far as technical details go, the story isn't much different than with Copy Fail, relying on exploiting a zero-copy operation by splicing a page cache descriptor into it. The different is that this time around, the fallible code is in the IPSec-related modules. The original vulnerability is "xfrm-ESP Page Cache Write", introduced in kernel commit cac2661c53f3 from 2017, and present across most distros. Since Ubuntu systems' AppArmor plugs that particular hole, the PoC chains a second exploit, "RxRPC Page-Cache Write", added in commit 2dc334f1a63a.

Google Preferred Source

Follow Tom's Hardware on Google News, or add us as a preferred source, to get our latest news, analysis, & reviews in your feeds.

Bruno Ferreira
Bruno Ferreira
Contributor

Bruno Ferreira is a contributing writer for Tom's Hardware. He has decades of experience with PC hardware and assorted sundries, alongside a career as a developer. He's obsessed with detail and has a tendency to ramble on the topics he loves. When not doing that, he's usually playing games, or at live music shows and festivals.

64 Comments Comment from the forums
  • bit_user
    Again, this is a local exploit. This should really be stated in the headline, which is too alarmist as written. It's not until the second paragraph that this is mentioned.

    Yes, it's bad (mainly in terms of being published before patches were fully out, as we've seen plenty of privilege escalation exploits before). However, in the thread about the Copy Fail exploit, we saw that some folks clearly got the impression the vulnerability directly enabled a remote attacker to gain root access, which it didn't.

    Please take care not to mislead people. I'd suggest the headline should characterize it as a privilege-escalation exploit, which is the usual way of describing them.
    Reply
  • chaos215bar2
    git clone https://github.com/V4bel/dirtyfrag.git && cd dirtyfrag && gcc -O0 -Wall -o exp exp.c -lutil && ./exp
    Is Tom's Hardware really sure they want to be recommending people download, build, and run code straight from some Github repository without even bothering to explain who's repository this is?
    I mean, I'm going to assume this has been vetted and the repository is from a very well trusted source, but telling people to execute code effectively straight from a repository without further vetting doesn't exactly seem like the kind of thing you want to be recommending people do in an article about the second Linux zero day to drop in quick succession.
    Reply
  • bit_user
    chaos215bar2 said:
    Is Tom's Hardware really sure they want to be recommending people download, build, and run code straight from some Github repository without even bothering to explain who's repository this is?
    Yeah, I'd say just link the repository. It has a readme which says how to execute it, if that's what someone chooses to do. But, you could also just study the source code by browsing it.
    Reply
  • ThisIsMe
    It’s not limited to local only. It can be remotely executed by any user that has remote access to the Linux device. This describes a large number of Linux devices. This could also affect systems that have other software running on them with possible vulnerabilities that let you execute code within its context. To try understating it is dangerous imho. It likely means much less to people who only have that one hobby-fulfilling Linux installation at home so they can say they have a Linux installation at home. However, this will affect many devices and enterprise Linux environments.
    Reply
  • rluker5
    I like that Tom's posted a fix.
    I rarely run Linux, mostly just to occasionally check it out, know almost nothing about it, but would have no problem copy/pasting that line to put myself at ease.
    Reply
  • bit_user
    ThisIsMe said:
    It’s not limited to local only. It can be remotely executed by any user that has remote access to the Linux device.
    What the local/remote thing is really meant to distinguish is whether or not you're authenticated. Someone who is not logged in to a machine and doesn't have a way of making an authenticated user execute arbitrary code cannot apply this exploit.

    ThisIsMe said:
    This could also affect systems that have other software running on them with possible vulnerabilities that let you execute code within its context.
    Yes, if there's a remote-access exploit, which grants access or execution privileges to a remote, unauthenticated actor, then they can combine such remote-access or code-execution exploits with privilege-escalation.
    Reply
  • JarredWaltonGPU
    bit_user said:
    What the local/remote thing is really meant to distinguish is whether or not you're authenticated. Someone who is not logged in to a machine and doesn't have a way of making an authenticated user execute arbitrary code cannot apply this exploit.


    Yes, if there's a remote-access exploit, which grants access or execution privileges to a remote, unauthenticated actor, then they can combine such remote-access or code-execution exploits with privilege-escalation.
    Seems like this would be pretty catastrophic in hosted Linux instances, as you could get root on any box. Hopefully the VMs are sandboxed off and can't affect other VMs on the same hardware. Still having full root access to any Linux system where you have an account is pretty bad. And any employee of a company who might be leaving could get root as well. Basically, while it doesn't inherently affect everyone, even a local account hack to get root is terrible and can't really be overstated as a serious issue. IMO
    Reply
  • bit_user
    JarredWaltonGPU said:
    Seems like this would be pretty catastrophic in hosted Linux instances, as you could get root on any box.
    Are you talking about gaining root, on the hypervisor? The hypervisor usually isn't Linux, and even with root on the hypervisor, properly-managed servers should use technologies like SEV that prevent the host from being able to see into the tenant VMs. At worst, having root on such a host would mean you can shutdown or de-provision guests, but you can't steal their data (unless using an unmitigated side-channel attack) or login to them.

    JarredWaltonGPU said:
    having full root access to any Linux system where you have an account is pretty bad. And any employee of a company who might be leaving could get root as well.
    The way most professional Linux environments are setup, normal employees only have an account on their local machines, which are not privileged in any way. So, getting root on your desktop won't then enable you to gain root access on a database server or fileserver.

    JarredWaltonGPU said:
    even a local account hack to get root is terrible and can't really be overstated as a serious issue. IMO
    Yes, it can be overstated. Like I said, it's not as if an unauthenticated remote user can directly use this exploit to access a box (root or otherwise). Nor (generally speaking) the other scenarios you outlined.
    Reply
  • wakuwaku
    bit_user said:
    Again, this is a local exploit. This should really be stated in the headline, which is too alarmist as written. It's not until the second paragraph that this is mentioned.

    Yes, it's bad (mainly in terms of being published before patches were fully out, as we've seen plenty of privilege escalation exploits before). However, in the thread about the Copy Fail exploit, we saw that some folks clearly got the impression the vulnerability directly enabled a remote attacker to gain root access, which it didn't.

    Please take care not to mislead people. I'd suggest the headline should characterize it as a privilege-escalation exploit, which is the usual way of describing them.
    SEO and keeping the AI fed is more important than the well being of Tom's people.
    Reply
  • vossile
    "and unlikely to affect the functioning of the vast majority of servers"

    I checked several of my servers. Nothing there. This sort of clickbaiting is annoying.
    Reply