You gave me a u32. I gave you root. (io_uring ZCRX freelist LPE)
MrBruh
167 points
95 comments
May 08, 2026
Related Discussions
Found 5 related stories in 77.5ms across 8,303 title embeddings via pgvector HNSW
- Claude wrote a full FreeBSD remote kernel RCE with root shell ishqdehlvi · 258 pts · April 01, 2026 · 42% similar
- Radicle: Sovereign {code forge} built on Git KolmogorovComp · 229 pts · May 15, 2026 · 39% similar
- Another day, another universal Linux LPE throwaway2027 · 16 pts · May 13, 2026 · 39% similar
- io_uring, libaio performance across Linux kernels and an unexpected IOMMU trap tanelpoder · 61 pts · March 24, 2026 · 39% similar
- "Dirty Frag" (CVE-2026-43284): The Second Linux Root Exploit in Eight Days ggallas · 31 pts · May 09, 2026 · 39% similar
Discussion Highlights (17 comments)
rvz
Another one. Linux is falling apart faster than it can assign these CVEs.
staticassertion
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).
rishabhaiover
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.
baq
What’s our prior for p(doom) today…?
FriedFishes
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
kro
CAP_NET/SYS_ADMIN is required for this. So this would be "not as bad" as the others.
stonegray
> “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?
SubiculumCode
Do most servers need this? Or can most of us 'sysctl -w kernel.io_uring_disabled=2 ' ?
shorden
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.
ctoth
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?
dundarious
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.
pamcake
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...
csmantle
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
JoeDohn
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).
himata4113
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.
somebudyelse
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
teo_zero
> 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?