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/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]

Or a follow up prompt: "find similar classes of bugs". Once the actual case has been layed out finding like bugs isn't too hard. I hear you on the creativity bit. Like any tool, AI can put blinders on. Using it to augment without it fully taking over your workflow is tough.

I don't follow. LLMs spotted these bugs in the first place. You seem to be saying that these discoveries are indications that they're bad for vulnerability discovery.

It’s very hard to see a root vuln similar to, but not the same as, another discovered by AI, as a lesson about AI not exploring.

Is there a counterfactual where you would say it explored well enough, besides both vulnerabilities published as one?

> When your workflow consists of asking questions and getting answers immediately, you don't get to see what's nearby.

That's why is very very important to just step out and use saved time to go for a walk, to a park, sit on a bench, listen do birds, close eyes and zoom out.

The state we are in is actually brilliant.

These are all page cache poisoning attacks (dirtyfrag, copyfail, dirtypipe). Maybe the page cache should have defense-in-depth measures for SUID binaries?

"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.

You can't sudo echo and redirect from the non-sudo shell like that.

    echo 3 | sudo tee /proc/sys/vm/drop_caches

    sudo sh -c 'echo 3 > /proc/sys/vm/drop_caches'

> ... 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)".

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.

> this is why we don't run as root

The entire point is that you can escalate to root

You mixed up the names vs. config options but yes killing those 3 options should make you "safe". No warranty.

it was published publicly by an unrelated third party

I assume because the rxrpc module is not loaded / provided and because unprivileged user namespaces are not allowed, which should be sufficient to mitigate. Curious if someone else has more details though.

Android has a lot of hardening and sandboxing that desktop Linux doesn't (and won't for UX reasons).

Because Android is not Linux, as much as some pretend it is.

In fact, given the official public APIs, Google could replace the Linux kernel with a BSD, and userspace wouldn't notice, other than rooted devices, and the OEMs themselves baking their Android distro.

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.

I just tried the exploit on a fresh Debian 13 droplet on digitalocean and it worked.

7 days from disclosure to publishing a how-to guide to get root to the entire planet doesn't scream "responsible" disclosure to me.

If your container has setuid binaries and these modules are loaded, yes.

New vulns are introduced to Linux every day. Fuzzers trigger every single day on Linux. No, nothing will improve here from AI.

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.

>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.

It’s two things. 1. Less eyes are on the bsds

2. Bsds don’t have the same optimizations that Linux has. Bsds generally try to pursue corrrectness

That being said there were just a bunch of vulnerabilities in freebsd

macOS has had its own dirty cow attack and I know there’s for sure more memory ones just based on the way the xnu kernel works.

So no Linux isn’t really worse per say

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.

Larger target.

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.

Everything in this comment is wrong.

This carries the same energy as "People will break into your car no matter what, so just leave your doors unlocked."

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.

https://xkcd.com/1200/