Linux security flaws Dirty Frag and Copy Fail are a good reminder to stay up to date

Note that both vulnerabilities are for a local user to gain root access.

They're being blown up out of proportion, if you ask me. And I'm not happy at all about the tools used to find them or the methods to reveal them before a patch could be written and distributed.

From the [issues](https://github.com/V4bel/dirtyfrag/issues) it seems Debian 12 is not affected, 13 and 14 are. I cannot say how trustworthy. The one-line-command also deletes the compromised cache, so infected systems should be clean after that command (if no malware got installed) if I understand it correctly. After this command it is still required to update once your distro delivers a patch. It seems the disclosure went wrong and got published too early, so distros may take a bit longer to deliver a patch than usual.

Quoting: MakiNote that both vulnerabilities are for a local user to gain root access.

Isn't that what privilege escalation is all about?
You got to local user, then you enhance your rights and become root.
I mean, it's not like "local user" means someone has to sit at your keyboard...

Last edited by Eike on 8 May 2026 at 9:34 am UTC

Quoting: Eike

Quoting: MakiNote that both vulnerabilities are for a local user to gain root access.

Isn't that what privilege escalation is all about?
You got to local user, then you enhance your rights and become root.
I mean, it's not like "local user" means someone has to sit at your keyboard...

No, but someone still needs to have a local user account. So this is a big problem for multi-user systems. But I imagine most of us operate their home machine for themselves only, so for most of "us" it's not immediately exploitable.

Quoting: Ehvis

Quoting: Eike

Quoting: MakiNote that both vulnerabilities are for a local user to gain root access.

Isn't that what privilege escalation is all about?
You got to local user, then you enhance your rights and become root.
I mean, it's not like "local user" means someone has to sit at your keyboard...

No, but someone still needs to have a local user account. So this is a big problem for multi-user systems. But I imagine most of us operate their home machine for themselves only, so for most of "us" it's not immediately exploitable.

It means someone has to run something locally, which you the single user do all the time.

However that something must be untrustworthy for there to be a threat. Most of what you use is from distro packages, so should be fine. Steam games aren't (closed source), so you just have to cross your fingers and trust the developer.

What you should never do, is download random binaries off of the internet and run them (because what is this, windows?)

Last edited by ShabbyX on 8 May 2026 at 12:11 pm UTC

Quoting: ShabbyXHowever that something must be untrustworthy for there to be a threat. Most of what you use is from distro packages, so should be fine. Steam games aren't (closed source), so you just have to cross your fingers and trust the developer.

True, but the funny thing is. Can those really do much more damage with a "Fail" or a "Frag" than they could do without it? If you're serious about security and do everything you can to separate things, the answer would be yes. But in practice it is most likely a no.

Quoting: Ehvis

Quoting: ShabbyXHowever that something must be untrustworthy for there to be a threat. Most of what you use is from distro packages, so should be fine. Steam games aren't (closed source), so you just have to cross your fingers and trust the developer.

True, but the funny thing is. Can those really do much more damage with a "Fail" or a "Frag" than they could do without it? If you're serious about security and do everything you can to separate things, the answer would be yes. But in practice it is most likely a no.

If you run a virus scanner it will most likely keep the Anti-virus killer at bay.
Tor-browser and if I remember correctly firefox have their own download folder sandboxing.
Apache sandboxes itself.
Python enforces sandboxing beyond calling user.
All flatpacks are sandboxed beyond calling user.
It's true that not all sandoxed perectly and obtaining user access is already a great breach, but if you want to have an indication what it limits simply run
 cat /etc/passwd
Each of the lines is a seperate user, which when it obtains root access suddenly can read your files.

Edit:
With the exception of root and your personal account ofcourse.

Last edited by LoudTechie on 8 May 2026 at 1:42 pm UTC

Copy Fail was for me a big thing, because it's for so far I can remember the first Linux specific n-day vulnerability that showed commoditization.

Explanation:
I've seen many attacks and attack attempts on Linux specific things.
The others all used zero-days.
This is the first time I see miscreants use an n-days in the Linux ecosystem.
I suspect this proofs I don't run an anti-virus scanner company, because it probably has happened before.
Yet, I don't know these examples.

Quoting: MakiNote that both vulnerabilities are for a local user to gain root access.

They're being blown up out of proportion, if you ask me. And I'm not happy at all about the tools used to find them or the methods to reveal them before a patch could be written and distributed.

I would caution against calling this "out of proportion". I think people wrongly assume that a "local" user has be at your keyboard to do damage. This is NOT the case. Everything you run is a "local" user, namely the account you typically work with. In this world of dependency hell, all it takes is a supply-chain attack. Someone could easily sneak some code into something you download and execute with your local privileges, and boom, you're toast.

Quoting: Kimyrielle

Quoting: MakiNote that both vulnerabilities are for a local user to gain root access.

They're being blown up out of proportion, if you ask me. And I'm not happy at all about the tools used to find them or the methods to reveal them before a patch could be written and distributed.

I would caution against calling this "out of proportion". I think people wrongly assume that a "local" user has be at your keyboard to do damage. This is NOT the case. Everything you run is a "local" user, namely the account you typically work with. In this world of dependency hell, all it takes is a supply-chain attack. Someone could easily sneak some code into something you download and execute with your local privileges, and boom, you're toast.

Out of proportion is still fair as there are articles/headlines everywhere that absolutely are doing that - you're not wrong that it's still important to deal with. The kind of important to update when you are able and not really wait, but no reason to cancel plans or act like the sky is falling sort of thing either - unless you run a web server of any type or are otherwise more susceptible than an average desktop user. I will also always beat the drum about caution regarding supply-chain in general as well, and remind people that rolling distributions and languages that download 50 billion modules to do anything in a similar manner are and always will be a risk nobody actually has to take.

Quoting: Ehvis

Quoting: Eike

Quoting: MakiNote that both vulnerabilities are for a local user to gain root access.

Isn't that what privilege escalation is all about?
You got to local user, then you enhance your rights and become root.
I mean, it's not like "local user" means someone has to sit at your keyboard...

No, but someone still needs to have a local user account. So this is a big problem for multi-user systems. But I imagine most of us operate their home machine for themselves only, so for most of "us" it's not immediately exploitable.

Not only for multi-user systems because if you combine this with an exploit in any userland programs that you use (say Firefox) or some daemon that accepts incoming connections from the outside (say sshd or apache) then an attacker will first gain local access over a network through that exploit and then use this exploit to gain root.

Quoting: ShabbyXWhat you should never do, is download random binaries off of the internet and run them (because what is this, windows?)

But where's the fun in that? What if you like to live dangerously? 🎲

Quoting: ShabbyXWhat you should never do, is download random binaries off of the internet and run them (because what is this, windows?)

You're on Gaming on Linux. So you probably game on Linux yourself. Therefore, you sure do download random binaries from the Internet.

Any Debian based Linux affected (I use MX-Linux with Liquorix kernel, it's not bleeding edge like Arch, but it's close):
$ sudo lsmod | grep esp4
okasion@tictac:~
$ sudo lsmod | grep esp6
okasion@tictac:~
$ sudo lsmod | grep rxrpc
okasion@tictac:~
$ echo 3 | sudo tee /proc/sys/vm/drop_caches
3

$ sudo update-initramfs -u -k all
update-initramfs: Generating /boot/initrd.img-6.18.16-2-liquorix-amd64
update-initramfs: Generating /boot/initrd.img-6.18.15-3-liquorix-amd64
update-initramfs: Generating /boot/initrd.img-6.14.2-1-liquorix-amd64

that's it, you're safe and the machine won't "forget" the changes when you reboot. It's practically the same Liam wrote with the generation of the kernels with the "fix".

There's also a namespace vulnerability, but I don't recommend applying the fix for now, it mostly affects servers, and can break some browsers and/or Docker/Kubernetes, etc:
sysctl kernel.unprivileged_userns_clone=0
THIS vulnerability it's the one a little bothering to me, I have it (as probably many of you) sysctl kernel.unprivileged_userns_clone=1 in my localhost, I use my computer 70% for dev, 30% for gaming, so it's important for me being able to run XFCE, Firefox, Docker, Kubernetes, things like that.

Quoting: anokasionAny Debian based Linux affected (I use MX-Linux with Liquorix kernel, it's not bleeding edge like Arch, but it's close):
$ sudo lsmod | grep esp4
okasion@tictac:~
$ sudo lsmod | grep esp6
okasion@tictac:~
$ sudo lsmod | grep rxrpc
okasion@tictac:~
$ echo 3 | sudo tee /proc/sys/vm/drop_caches
3

$ sudo update-initramfs -u -k all
update-initramfs: Generating /boot/initrd.img-6.18.16-2-liquorix-amd64
update-initramfs: Generating /boot/initrd.img-6.18.15-3-liquorix-amd64
update-initramfs: Generating /boot/initrd.img-6.14.2-1-liquorix-amd64

that's it, you're safe and the machine won't "forget" the changes when you reboot. It's practically the same Liam wrote with the generation of the kernels with the "fix".

There's also a namespace vulnerability, but I don't recommend applying the fix for now, it mostly affects servers, and can break some browsers and/or Docker/Kubernetes, etc:
sysctl kernel.unprivileged_userns_clone=0
THIS vulnerability it's the one a little bothering to me, I have it (as probably many of you) sysctl kernel.unprivileged_userns_clone=1 in my localhost, I use my computer 70% for dev, 30% for gaming, so it's important for me being able to run XFCE, Firefox, Docker, Kubernetes, things like that.

Sorry but what you wrote is no fix at all, you simply checked if the module was currently loaded (and they won't be, the exploit however will dynamically load them in). What Liam wrote in the article was a rule to blacklist those modules so they are never loaded.

Quoting: LoudTechieTor-browser and if I remember correctly firefox have their own download folder sandboxing.

Regarding Firefox, not to my knowledge. On my systems, Firefox defaults to my Download folder. No sandboxing that I'm aware of -- unless this is a feature I have to enable.

Quoting: Caldathras

Quoting: LoudTechieTor-browser and if I remember correctly firefox have their own download folder sandboxing.

Regarding Firefox, not to my knowledge. On my systems, Firefox defaults to my Download folder. No sandboxing that I'm aware of -- unless this is a feature I have to enable.

Yeah it should default to your download folder, but can you look beyond it. Can you work in your document folder.
Tor-browser maintains its own seperate folder, but I thought firefox limited itself to only the download folder.
Based on what you said I would assume the answer is no, but I still wanted to clarify what I meant.

Quoting: LoudTechie

Quoting: Caldathras

Quoting: LoudTechieTor-browser and if I remember correctly firefox have their own download folder sandboxing.

Regarding Firefox, not to my knowledge. On my systems, Firefox defaults to my Download folder. No sandboxing that I'm aware of -- unless this is a feature I have to enable.

Yeah it should default to your download folder, but can you look beyond it. Can you work in your document folder.
Tor-browser maintains its own seperate folder, but I thought firefox limited itself to only the download folder.
Based on what you said I would assume the answer is no, but I still wanted to clarify what I meant.

Problem here though is that sandboxing will not protect against this. Sandboxing protects against malicious userspace or userspace code with open exploits in them IF and only IF there also are no privilege escalation vulnerability in the running kernel.