Top
Best
New

Posted by MrBruh 15 hours ago

You gave me a u32. I gave you root. (io_uring ZCRX freelist LPE)(ze3tar.github.io)
187 points | 109 comments
FriedFishes 14 hours ago|
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

stonegray 14 hours ago||
> “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?

PlasmaPower 13 hours ago||
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.

delusional 11 hours ago||
I don't think namepsace CAP_SYS_ADMIM grants you access to write non namespaces sysctls like modprobe_path
PlasmaPower 10 hours ago||
You're probably right, but that seems like the less important part of this. At that point you've already got an out-of-bounds write. Another comment speculated that you could use PageJack as an alternative exploit path once you have that primitive: https://news.ycombinator.com/item?id=48069623
pizzalife 13 hours ago||
Right. `CAP_SYS_ADMIN` is for all intents and purposes equivalent to root.
rishabhaiover 14 hours ago||
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.
spindump8930 14 hours ago||
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).
NitpickLawyer 14 hours ago|||
> 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.

john_strinlai 14 hours ago|||
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.
elija 9 hours ago|||
In some sense, I wonder if non-open-source is "safer" since LLMs can't mass scan the code for exploits.
overboard2 7 hours ago||
Maybe for a while, but there's nothing stopping LLMs from examining disassembler output.
LtdJorge 1 hour ago||
Security through obscurity
majorchord 14 hours ago|||
AI is happening.
cachius 14 hours ago||
In each recent case?
gordonhart 14 hours ago||
AI assistance was explicitly disclosed on yesterday's. Today's has Claude as one of two contributors on this GitHub Pages site at least so it's also very likely.

Agents are capable of finding this kind of stuff now and people are having a field day using them to find high-profile CVEs for fun or profit.

calebhwin 5 hours ago|||
It's actually the perfect evergreen content to discuss on HN in an age where so much else is AI generated.
gilrain 14 hours ago|||
Automated vulnerability discovery via LLM.
ryandrake 12 hours ago|||
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?
Arcuru 11 hours ago|||
The Anthropic researchers have said their flow is as simple as:

1. Pick a file to seed as a starting place.

2. Ask the LLM (in an agent harness) to find a vulnerability by starting there.

3. If it claims to have found something, ask another one to create an exploit/verify it/prove it or whatever.

4. If both conclude there is a vuln, then with the latest models you almost certainly found something real.

Just run it against every file in a repo, or select a subset, or have an LLM select files with a simple "what X files look likely to have vulns?".

So basically yes, it is that simple. It's just a matter of having the money to pay for the tokens.

ryandrake 10 hours ago||
Thanks for the reply. Pretty remarkable.
huflungdung 11 hours ago|||
[dead]
pixl97 13 hours ago|||
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.
microtonal 2 hours ago|||
I agree. It is not like Mythos or other LLMs are insanely smart/superhuman. Many of these vulnerabilities could be discovered fairly easily by trained human experts as well. The problem is more that it requires an insane amount of attention and time of highly-paid experts to shake out these issues vs. an LLM that never gets tired and can analyze a large amount of code at low cost.

Linus' law was wrong because there were never enough (qualified) eyeballs to check the code. LLMs provide an ample supply of eyeballs (though it's not a benefit to open source, since proprietary developers can use the same LLMs).

pjmlp 3 hours ago|||
Same applies to them being good enough to program, but many are so focused on source code generation that they don't get the whole picture.

Thanks to agents and tool calling, there are now business cases that can be fully described by AI tooling, the next step in microservices, serverless and what not.

Naturally with a much smaller team than what was required previously.

sva_ 10 hours ago|||
A mix of AI and hybrid warfare.
raverbashing 2 hours ago|||
I wonder where are the Rust naysayers hiding now

C code is broken - period

themafia 11 hours ago|||
Perhaps it was the prior quiescent period that was the anomaly.
jdub 2 hours ago||
... there's also a bit of a frequency illusion factor.
pamcake 10 hours ago||
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...

javascripthater 9 hours ago|
big ups pimp
sherr 4 hours ago||
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.
kro 14 hours ago||
CAP_NET/SYS_ADMIN is required for this. So this would be "not as bad" as the others.
kam 12 hours ago||
Also "The page pool is only created on a real ZCRX-capable NIC (mlx5 ConnectX-6+, Intel E800, NFP)"
t0mas88 12 hours ago||
It could work for container escape?
kro 2 hours ago||
Containers, even with root user, are often stripped of these capabilities unless --privileged
somebudyelse 9 hours ago||
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

pocksuppet 3 hours ago|
Aren't CF2 and DF the same exploit?
staticassertion 14 hours ago||
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).
otterley 13 hours ago|
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.
vsgherzi 13 hours ago||
super curious on this one as well, last I heard they've been enabling it slowly
shorden 12 hours ago||
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.
dundarious 11 hours ago|
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.

More comments...