I can't quite make out if this is new or not. The attack vector here seems congruent with a similar exploit from a couple months ago [1]
But still might be an open threat. On the email thread Jens seems to think that this is already patched and in stable, he also points out that for this exploit to work (as written in the article) you already need escalated privileges [2] Catchy title though.
No, you can grant yourself this inside an unprivileged user namespace. `unshare -Ur capsh --print` lists the capabilities inside a user namespace and demonstrates that it has both CAP_SYS_ADMIN and CAP_NET_ADMIN.
Almost all distros allow unprivileged user namespaces, and in my opinion this is the right decision, because they're important for browser sandboxing which I think is more important than LPEs.
What is happening? I see multiple outages and CVEs is being reported on HN's front page. I've never seen these many security/incident related posts on HN's front page.
Some combination of reporting bias given concerns about LLM security capabilities and actual new vulnerabilities found with LLM assistance. Even if exploits and outages are unrelated to LLMs, I'm certainly thinking about whether claude could build these things (or if actors already have).
Slowly at first, and then suddenly. AI assisted anything follows this trend. As capabilities improve, new avenues become "good enough" to automate. Today is security.
i believe a good portion of the cves hitting the front page are moreso because they are ai-related (found partially/in whole by ai) and make for quick upvotes.
Anyone care to share which models and which prompts actually lead to finding these kinds of vulnerabilities? Or the narrowing-down workflow that can get an LLM to discover them? Surely just telling claude "Find all vulnerabilities in this project LOL" isn't enough? I hope?
Everyone was talking about how Mythos was overblown marketing, and while it may be, they missed the forest for the trees. Capabilities have been escalating for a year now and we're at the point of widespread impact. I don't suspect we'll see a slowdown for a long time.
Desktop and server vulnerabilities are one thing. At least many are actively maintained and will get patched. I have a concern about all the common and cheap internet firewalls and routers that are around, running old software and kernels. Many or most will not get patched. I have some Ubiquiti boxes that are long out of support and run old kernels for instance. The hope is only that there's nothing they expose that gets hit.
io-uring is a security nightmare. Constant privescs and a powerful primitive for syscall smuggling. Worth considering disabling it outright (already the case for most containers afaik).
Interesting, I haven't tested this myself but intuitively I think that a 4 byte OOB write is plenty for a data-only attack like [PageJack](https://i.blackhat.com/BH-US-24/Presentations/US24-Qian-Page...), so I don't think hardening against the KASLR leaks discussed in OP would necessarily save you from this attack.
How many systems have the relevant NICs, and followed the non-automatic setup steps in https://docs.kernel.org/networking/iou-zcrx.html, and are not running within a VM/container disabling io_uring?
This seems on the low impact end of the numerous historical io_uring issues.
Obviously the way to prevent this is by bounds checking, which is literally in the `770594e` patch. It's just a bug and they happen routinely in all languages. Since this is doing pointer arithmetic, it could just as easily happen in unsafe Rust, for example.
sure, but with unsafe Rust you have a very clear marking for the section of code that requires additional care and attention. it is also customary to include a "SAFETY" comment outlining why using unsafe is OK here
But one would have to explicitly choose to use unsafe Rust for this instead of ordinary safe Rust. And safe Rust has no particular difficulty writing to slots in an array or slice or vector specified by their index.
I first read this from the author's posting to oss-security. Turns out that the author did agree to revise the blog post for the "admin cap for root shell" part [^0]. [^1] would probably tell more.
So this is another CVE? Or am I misreading this one? "Copy‑fail", "DirtyFrag", now "IUrinegOnYou :)"?
Joke aside, we'll see more CVEs in the coming months, and in a sense that's good: it leaves less maneuvering room for bad actors (especially those selling them to the highest bidder).
If this many are public right now, what does that say about the dark matter of private ones? What's the typical public-private rate for this sort of thing/can someone help me calibrate my base rate expectations?
high privilege access required (CAP/NET admin), containers / sandboxing wins once again.
Can we make sandboxing the new default now? Flatpak does a good job, but we're still pretty far away for apt/yum/pacman installed packages. AppArmor was a decent step forward, but clearly not enough.
As other people said in this thread: so many devices won't be patched. And that can easily lead to users and manufacturers moving away from Linux. Linux is in a glass house.
Government agencies probably already have half of these exploits in their private toolbox for years now. Finding and patching them is good, but there probably needs to be some systematic change to prevent them rather than just patching bugs when they get found.
Linux is "falling apart" because it's the highest-profile open source project people can point LLM agents at to find CVEs. It'll come out the other end of this hardened by all of the attention it's getting, but the next few months/years will be... bumpy.
I can't quite make out if this is new or not. The attack vector here seems congruent with a similar exploit from a couple months ago [1]
But still might be an open threat. On the email thread Jens seems to think that this is already patched and in stable, he also points out that for this exploit to work (as written in the article) you already need escalated privileges [2] Catchy title though.
[1] https://snailsploit.com/security-research/general/io-uring-z...
[2] https://seclists.org/oss-sec/2026/q2/448
> “and is writable with CAP_SYS_ADMIN”
Am I reading this wrong or is this just a way of executing an arbitrary binary with uid=0 if you have both CAP_NET_ADMIN and CAP_SYS_ADMIN?
If you can write modprobe_path, is it really news that you can find a way to execute code?
No, you can grant yourself this inside an unprivileged user namespace. `unshare -Ur capsh --print` lists the capabilities inside a user namespace and demonstrates that it has both CAP_SYS_ADMIN and CAP_NET_ADMIN.
Almost all distros allow unprivileged user namespaces, and in my opinion this is the right decision, because they're important for browser sandboxing which I think is more important than LPEs.
I don't think namepsace CAP_SYS_ADMIM grants you access to write non namespaces sysctls like modprobe_path
1 reply →
Right. `CAP_SYS_ADMIN` is for all intents and purposes equivalent to root.
What is happening? I see multiple outages and CVEs is being reported on HN's front page. I've never seen these many security/incident related posts on HN's front page.
Some combination of reporting bias given concerns about LLM security capabilities and actual new vulnerabilities found with LLM assistance. Even if exploits and outages are unrelated to LLMs, I'm certainly thinking about whether claude could build these things (or if actors already have).
> What is happening?
Slowly at first, and then suddenly. AI assisted anything follows this trend. As capabilities improve, new avenues become "good enough" to automate. Today is security.
i believe a good portion of the cves hitting the front page are moreso because they are ai-related (found partially/in whole by ai) and make for quick upvotes.
In some sense, I wonder if non-open-source is "safer" since LLMs can't mass scan the code for exploits.
Maybe for a while, but there's nothing stopping LLMs from examining disassembler output.
It's actually the perfect evergreen content to discuss on HN in an age where so much else is AI generated.
AI is happening.
In each recent case?
1 reply →
I wonder where are the Rust naysayers hiding now
C code is broken - period
Automated vulnerability discovery via LLM.
Anyone care to share which models and which prompts actually lead to finding these kinds of vulnerabilities? Or the narrowing-down workflow that can get an LLM to discover them? Surely just telling claude "Find all vulnerabilities in this project LOL" isn't enough? I hope?
3 replies →
Everyone was talking about how Mythos was overblown marketing, and while it may be, they missed the forest for the trees. Capabilities have been escalating for a year now and we're at the point of widespread impact. I don't suspect we'll see a slowdown for a long time.
2 replies →
A mix of AI and hybrid warfare.
... there's also a bit of a frequency illusion factor.
Perhaps it was the prior quiescent period that was the anomaly.
Desktop and server vulnerabilities are one thing. At least many are actively maintained and will get patched. I have a concern about all the common and cheap internet firewalls and routers that are around, running old software and kernels. Many or most will not get patched. I have some Ubiquiti boxes that are long out of support and run old kernels for instance. The hope is only that there's nothing they expose that gets hit.
This kind of post really shouldn't require client-side js — from third-party domain — to read...
static markdown version: https://raw.githubusercontent.com/ze3tar/ze3tar.github.io/9d...
big ups pimp
CAP_NET/SYS_ADMIN is required for this. So this would be "not as bad" as the others.
Also "The page pool is only created on a real ZCRX-capable NIC (mlx5 ConnectX-6+, Intel E800, NFP)"
It could work for container escape?
Containers, even with root user, are often stripped of these capabilities unless --privileged
Let's see... That's 4 Linux LPEs in the last 10 days?
Copy Fail [1]
Copy Fail 2: Electric Boogaloo [2]
Dirty Frag [3]
And now this...
[1]: https://copy.fail
[2]: https://github.com/0xdeadbeefnetwork/Copy_Fail2-Electric_Boo...
[3]: https://github.com/V4bel/dirtyfrag
Aren't CF2 and DF the same exploit?
io-uring is a security nightmare. Constant privescs and a powerful primitive for syscall smuggling. Worth considering disabling it outright (already the case for most containers afaik).
At one point, Google disabled io_uring on its production servers (https://security.googleblog.com/2023/06/learnings-from-kctf-...) - I don't know whether this is still true, though. Perhaps a Google can confirm.
super curious on this one as well, last I heard they've been enabling it slowly
Interesting, I haven't tested this myself but intuitively I think that a 4 byte OOB write is plenty for a data-only attack like [PageJack](https://i.blackhat.com/BH-US-24/Presentations/US24-Qian-Page...), so I don't think hardening against the KASLR leaks discussed in OP would necessarily save you from this attack.
How many systems have the relevant NICs, and followed the non-automatic setup steps in https://docs.kernel.org/networking/iou-zcrx.html, and are not running within a VM/container disabling io_uring?
This seems on the low impact end of the numerous historical io_uring issues.
Interesting and important all the same.
[flagged]
> "No way to prevent this", Says Only Language Where This Regularly Happens
also see lib0xc etc.: https://news.ycombinator.com/item?id=47978834
NOTE: This is a design document and the feature is not available for users yet.
https://clang.llvm.org/docs/BoundsSafety.html
Obviously the way to prevent this is by bounds checking, which is literally in the `770594e` patch. It's just a bug and they happen routinely in all languages. Since this is doing pointer arithmetic, it could just as easily happen in unsafe Rust, for example.
Like they said, "no way to prevent this" (kind of bug from happening again).
11 replies →
sure, but with unsafe Rust you have a very clear marking for the section of code that requires additional care and attention. it is also customary to include a "SAFETY" comment outlining why using unsafe is OK here
4 replies →
But one would have to explicitly choose to use unsafe Rust for this instead of ordinary safe Rust. And safe Rust has no particular difficulty writing to slots in an array or slice or vector specified by their index.
17 replies →
That's not prevention. That's remediation.
Surely nobody could create a better language in 50 years. Surely we can't fix these issues.
And you see a lot of other languages being used to create operating systems with complicated multiprocessor and locking semantics?
> Affected: Linux 6.15 – 6.19 [...] Fix: commit 770594e (not yet in any stable branch at time of writing).
Is it considered good pactice to publish a vulnerability not yet patched in any stable branch?
I first read this from the author's posting to oss-security. Turns out that the author did agree to revise the blog post for the "admin cap for root shell" part [^0]. [^1] would probably tell more.
The title looks like clickbait to me.
[^0]: https://www.openwall.com/lists/oss-security/2026/05/08/10
[^1]: https://www.openwall.com/lists/oss-security/2026/05/08/14
Do most servers need this? Or can most of us 'sysctl -w kernel.io_uring_disabled=2 ' ?
So this is another CVE? Or am I misreading this one? "Copy‑fail", "DirtyFrag", now "IUrinegOnYou :)"?
Joke aside, we'll see more CVEs in the coming months, and in a sense that's good: it leaves less maneuvering room for bad actors (especially those selling them to the highest bidder).
If this many are public right now, what does that say about the dark matter of private ones? What's the typical public-private rate for this sort of thing/can someone help me calibrate my base rate expectations?
What’s our prior for p(doom) today…?
high privilege access required (CAP/NET admin), containers / sandboxing wins once again.
Can we make sandboxing the new default now? Flatpak does a good job, but we're still pretty far away for apt/yum/pacman installed packages. AppArmor was a decent step forward, but clearly not enough.
Yes on Android, iDevices, macOS, Windows (UWP, Win32 boxing), Qube OS, but it remains a controversial topic in GNU/Linux land.
[dead]
Another one.
Linux is falling apart faster than it can assign these CVEs.
Falling apart? You mean getting stronger? Every single one of these is an existing hole being patched. It isn't making new holes
As other people said in this thread: so many devices won't be patched. And that can easily lead to users and manufacturers moving away from Linux. Linux is in a glass house.
Government agencies probably already have half of these exploits in their private toolbox for years now. Finding and patching them is good, but there probably needs to be some systematic change to prevent them rather than just patching bugs when they get found.
2 replies →
I remember when people used to joke with Windows security and something like that would never happen on Linux, well..
Linux is "falling apart" because it's the highest-profile open source project people can point LLM agents at to find CVEs. It'll come out the other end of this hardened by all of the attention it's getting, but the next few months/years will be... bumpy.
perhaps this will lead to better AppArmor and SELinux defaults?
People will just turn SELinux off rather than have to go through the horrible tooling when it breaks a regular use case.
3 replies →
How's BSD doing? How about Amazon Linux?
Amazon Linux is a Linux distro? Though, yes, I would like to know how the BSDs are doing.
1 reply →
FreeBSD is getting piles of security updates lately too. Not sure about the other BSDs.
And Windows?
2 replies →