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.
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.
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.
From what I understand, the copy fail bug was found by researcher who noticed something weird and then using AI to scan the codebase for instances where that becomes a problem.
I bet that with a slightly looser prompt/harness, the LLM could have found these twin bugs too.
Yet at the same time, I also think that if the human researcher had manually scanned the code, he'd have noticed these bugs too.
FWIW I do think LLMs are great tools for finding vulnerabilities in general. Just that they were visibly not optimally applied in this case.
I don't think the copy.fail people understood the issue they found, as is evident by the heavy focus on AF_ALG/aead_algif, which is essentially "innocent" as we're seeing here.
I think LLMs are great for vulnerability discovery, but you need to not skimp on the legwork and understanding what even you just found there.
No, they did not. Careful of falling for the psychosis.
> This finding was AI-assisted, but began with an insight from Theori researcher Taeyang Lee, who was studying how the Linux crypto subsystem interacts with page-cache-backed data.
> 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.
These are all page cache poisoning attacks (dirtyfrag, copyfail, dirtypipe). Maybe the page cache should have defense-in-depth measures for SUID binaries?
splice is documented to return EBADF if "One or both file descriptors are not valid, or do not have proper read-write mode."
So it seems surprising to me that you can call it when the out fd is not writable? But I didn't retain the information about the vulnerability, so I'm missing something. There was something about copy on write, IIRC?
"proper read-write mode" for the input fd is reading only. The exploit is writing to the splice() input fd.
Also, NB, I said permission check, not mode check. The input fd to splice can and will be open for only reading quite often. Doesn't mean the kernel can't still do a write permission check.
(Except I didn't say that here. Oops. Getting confused with my posts.)
OK, I may likely have too much sleep debt to understand, but given the bug is that splice can write to the input fd, you're suggesting maybe splice should only let you use an input fd if the process has access to write to it?
But splice is a more or less a generalization of sendfile, and sendfile is often used for webserving where the serving process does not have ownership of the documents it is serving. It doesn't make sense to limit splice such that it can't do the task it was built for. Maybe splice should just not write to the input fd? :P
True! Building protections (e.g. physical pages in the page cache are not writeable 100% of the time) just for executables has of course countless circumventions as well (e.g. config files). Yeah, there is probably not that much to be done there, actually. Looking at some of the diffs it seems to me like the kernel makes it really not particularly obvious when/how this goes wrong. E.g. the patch for this is to look at an additional flag on the socket buffer to fix an arbitrary page cache write. This feels rather action at a distance. Logically this of course makes sense, the whole point of splice et al is to feed data from one file-like into another file-like, whatever those ends might be. That erases the underlying provenance of the data.
"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."
"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.
>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 so that people visiting this thread dont need to poke around a bunch of different places.
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.]
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.
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)".
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
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.
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.
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?
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?
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.
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.
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.
It absolutely is Linux, and yes the JVM could absolutely run on something else. But it is Linux and you can run Linux binaries directly on it - that just isn’t how it is used by end users.
No you cannot, the NDK has a specific set of oficial APIS, and the Android team feels in the right to kill any application that doesn't follow the law of Android land.
Some folks like the termux rebels, occasionally find out there is a sherif in town.
> As documented in the Android N behavioral changes, to protect Android users and apps from unforeseen crashes, Android N will restrict which libraries your C/C++ code can link against at runtime. As a result, if your app uses any private symbols from platform libraries, you will need to update it to either use the public NDK APIs or to include its own copy of those libraries. Some libraries are public: the NDK exposes libandroid, libc, libcamera2ndk, libdl, libGLES, libjnigraphics, liblog, libm, libmediandk, libOpenMAXAL, libOpenSLES, libstdc++, libvulkan, and libz as part of the NDK API. Other libraries are private, and Android N only allows access to them for platform HALs, system daemons, and the like. If you aren’t sure whether your app uses private libraries, you can immediately check it for warnings on the N Developer Preview.
That's specific libraries, when using the default linker. You could construct that same behavior on desktop linux too. And you can avoid it equally well on Android - you can statically-link things just fine, you can use libraries you actually control, and presumably use a custom linker if desired. It's utterly non-surprising that "you run code you don't control" results in "said code...can do arbitrary things for unsupported use". (Never mind that, instead of a "sherif", they could've just renamed all private symbols, or just naturally replaced them over time, breaking your code all the same, just in a more confusing way)
Also some obligatory Linux vs GNU/Linux comment. (and it's not like GNU/Linux doesn't ever change under your feet - see the glibc DT_HASH debacle)
That's all user space platform specifics, it has no relation to your previous statement where you said 'android is not linux'.
Someone can statically build a freestanding executable/so targetting arm64 linux (specifically the right android linux kernel version) and it will run fine on Android. The syscall interface, process model, file descriptors, signals, memory mapping, all of this is Linux, this is what people mean when they say Android is just Linux.
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.
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.
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-Kuber...
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?
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.
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?
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.
- 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.
Unfortunately that is not what they proposed. To stretch the automotive analogy too far, you could say: if you invite a carjacker in, their seatbelt is not going to stop them from carjacking you.
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.
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.
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]
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.
(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.
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.
From what I understand, the copy fail bug was found by researcher who noticed something weird and then using AI to scan the codebase for instances where that becomes a problem.
I bet that with a slightly looser prompt/harness, the LLM could have found these twin bugs too.
Yet at the same time, I also think that if the human researcher had manually scanned the code, he'd have noticed these bugs too.
FWIW I do think LLMs are great tools for finding vulnerabilities in general. Just that they were visibly not optimally applied in this case.
I don't think the copy.fail people understood the issue they found, as is evident by the heavy focus on AF_ALG/aead_algif, which is essentially "innocent" as we're seeing here.
I think LLMs are great for vulnerability discovery, but you need to not skimp on the legwork and understanding what even you just found there.
Right but without the LLM the bug doesn't get found at all.
Yes, I agree. I'm not the GP poster.
No, they did not. Careful of falling for the psychosis.
> This finding was AI-assisted, but began with an insight from Theori researcher Taeyang Lee, who was studying how the Linux crypto subsystem interacts with page-cache-backed data.
https://xint.io/blog/copy-fail-linux-distributions
Theori is an AI security research firm.
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?
SUID mitigations have nothing to do with the vulnerability itself - just the exploit.
If there's a root cronjob that runs a world readable binary, you could modify it in the page cache and exploit it that way.
Modifying the page cache is a really strong primitive with countless ways to exploit it.
splice() should maybe generally refuse to operate on things you can't write to.
splice is documented to return EBADF if "One or both file descriptors are not valid, or do not have proper read-write mode."
So it seems surprising to me that you can call it when the out fd is not writable? But I didn't retain the information about the vulnerability, so I'm missing something. There was something about copy on write, IIRC?
"proper read-write mode" for the input fd is reading only. The exploit is writing to the splice() input fd.
Also, NB, I said permission check, not mode check. The input fd to splice can and will be open for only reading quite often. Doesn't mean the kernel can't still do a write permission check.
(Except I didn't say that here. Oops. Getting confused with my posts.)
OK, I may likely have too much sleep debt to understand, but given the bug is that splice can write to the input fd, you're suggesting maybe splice should only let you use an input fd if the process has access to write to it?
But splice is a more or less a generalization of sendfile, and sendfile is often used for webserving where the serving process does not have ownership of the documents it is serving. It doesn't make sense to limit splice such that it can't do the task it was built for. Maybe splice should just not write to the input fd? :P
True! Building protections (e.g. physical pages in the page cache are not writeable 100% of the time) just for executables has of course countless circumventions as well (e.g. config files). Yeah, there is probably not that much to be done there, actually. Looking at some of the diffs it seems to me like the kernel makes it really not particularly obvious when/how this goes wrong. E.g. the patch for this is to look at an additional flag on the socket buffer to fix an arbitrary page cache write. This feels rather action at a distance. Logically this of course makes sense, the whole point of splice et al is to feed data from one file-like into another file-like, whatever those ends might be. That erases the underlying provenance of the data.
"Because the embargo has now been broken, no patches or CVEs exist for these vulnerabilities."
link: https://github.com/V4bel/dirtyfrag
detailed writeup: 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."
conversation around the mitigation suggests you need a reboot or run this after the above on already-exploited machines:"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.
>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 so that people visiting this thread dont need to poke around a bunch of different places.
You can't sudo echo and redirect from the non-sudo shell like that.
or Also fixed your typo in /proc...Or more simply, use
echo 3 | sudo tee /proc/sys/vm/drop_caches
Also try:
thanks. copy pasting from the github via my phone, and should have taken the extra few mins
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.]
Tested Amazon Linux 2023 and it doesn't appear to be vulnerable in the default configuration. Would be interested if anyone finds anything different.
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.
> ... 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)".
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
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.
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
If you don't need it (rootless containers), you can disable unprivileged userns to block these two:
May also break sandboxes (e.g. browser) though.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?
You mixed up the names vs. config options but yes killing those 3 options should make you "safe". No warranty.
damn you're right, thx
I'm curious what broke the embargo. Did it leak or did a third party find it independently?
it was published publicly by an unrelated third party
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?
The commit for the fix was public. Someone noticed. An exploit was published.
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?
Following disclosure procedures? The main cause that kills the need to take security seriously.
This again does not work under Android, at least in termux compiled with clang/gcc.
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).
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.
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.
It absolutely is Linux, and yes the JVM could absolutely run on something else. But it is Linux and you can run Linux binaries directly on it - that just isn’t how it is used by end users.
No you cannot, the NDK has a specific set of oficial APIS, and the Android team feels in the right to kill any application that doesn't follow the law of Android land.
Some folks like the termux rebels, occasionally find out there is a sherif in town.
> As documented in the Android N behavioral changes, to protect Android users and apps from unforeseen crashes, Android N will restrict which libraries your C/C++ code can link against at runtime. As a result, if your app uses any private symbols from platform libraries, you will need to update it to either use the public NDK APIs or to include its own copy of those libraries. Some libraries are public: the NDK exposes libandroid, libc, libcamera2ndk, libdl, libGLES, libjnigraphics, liblog, libm, libmediandk, libOpenMAXAL, libOpenSLES, libstdc++, libvulkan, and libz as part of the NDK API. Other libraries are private, and Android N only allows access to them for platform HALs, system daemons, and the like. If you aren’t sure whether your app uses private libraries, you can immediately check it for warnings on the N Developer Preview.
https://android-developers.googleblog.com/2016/06/improving-...
These stable APIs,
https://developer.android.com/ndk/guides/stable_apis
That's specific libraries, when using the default linker. You could construct that same behavior on desktop linux too. And you can avoid it equally well on Android - you can statically-link things just fine, you can use libraries you actually control, and presumably use a custom linker if desired. It's utterly non-surprising that "you run code you don't control" results in "said code...can do arbitrary things for unsupported use". (Never mind that, instead of a "sherif", they could've just renamed all private symbols, or just naturally replaced them over time, breaking your code all the same, just in a more confusing way)
Also some obligatory Linux vs GNU/Linux comment. (and it's not like GNU/Linux doesn't ever change under your feet - see the glibc DT_HASH debacle)
That's all user space platform specifics, it has no relation to your previous statement where you said 'android is not linux'.
Someone can statically build a freestanding executable/so targetting arm64 linux (specifically the right android linux kernel version) and it will run fine on Android. The syscall interface, process model, file descriptors, signals, memory mapping, all of this is Linux, this is what people mean when they say Android is just Linux.
https://www.androidpolice.com/google-support-linux-kernels-a...
Google relies on Linux LTS kernels. When the Linux LTS team dropped support from 6 years down to 2 years, Google stepped in to cover the 4-year gap.
It is Linux. It's basically a distro.
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.
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.
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.
7 days from disclosure to publishing a how-to guide to get root to the entire planet doesn't scream "responsible" disclosure to me.
Its not the reporter's fault that other people broke the embargo.
They don't have to publish a working exploit as soon as the embargo is broken, though.
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?
anyone who will use the exploit maliciously will immediately and trivially be able to create a working exploit.
Why not? There has already been a working exploit floating around, at least now it comes from an authoritative source.
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.
WTF cares? Publish them without disclosure is the true way, otherwise noone would care about security and your data.
can this also be used to obtain container escape ?
If your container has setuid binaries and these modules are loaded, yes.
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-Kuber...
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.
And your containers need to have specific capabilities enabled, which aren't by default on kubernetes and podman.
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?
New vulns are introduced to Linux every day. Fuzzers trigger every single day on Linux. No, nothing will improve here from AI.
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.
There is a finite number of bugs and betters tools that find them mean there is less bugs in the code.
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.
So umm... should I rush home and turn off all my computers?
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.
Here we go again
Was the embargo ACTUALLY broken or is somebody just looking for attention?
>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.
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?
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.
This is really not a correct statement beyond the fact that both are a type of Unix.
Linux is not Unix: it is not derived from AT&T Unix.
Larger target.
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.
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.
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.
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.
Half the point is that you should always assume that there exists a complete LPE bug.
But yes, micro VMs are a great idea!
Everything in this comment is wrong.
Technically yes. Practically, I disagree.
The part where you run everything as root is particularly stupid. But yes, user isolation has been weakened quite a bit.
This carries the same energy as "People will break into your car no matter what, so just leave your doors unlocked."
The energy here is "so don't leave anything valuable in your car".
Unfortunately that is not what they proposed. To stretch the automotive analogy too far, you could say: if you invite a carjacker in, their seatbelt is not going to stop them from carjacking you.
"Avoid shared-kernel attack surfaces" is not an unreasonable proposition in 2026.
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/