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.