Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

You gave me a u32. I gave you root. (io_uring ZCRX freelist LPE)

ze3tar.github.io

Post reply on HN
Print view View original

71–80 of 152 posts

Re: You gave me a u32. I gave you root. (io_uring ZCRX freelist LPE)

#71

Post by saghm »

greiskul wrote: post #59
Jtsummers wrote: post #56

Earlier quoted context omitted.

> Doing unsafe stuff is pretty inevitable if you want to do anything non-hello-world-ish. So the vast majority of Rust projects involve writing at least one unsafe block? Is that really your claim?

And even if you do end up writing an unsafe block, that should be a massive flag that the code in said block should deserve extra comments on why it is safe, and extra unit tests on verifying that it does not blow up. How do you know the unsafe operation is safe? What are the preconditions the code block has? Write it down, review it, test it.

Exactly; I feel like a lot of people seem to misunderstand what Rust is trying to solve. It's fundamentally not trying to make unsafe code impossible; it's making the number of places you need to audit it a tiny fraction of your codebase compared to needing to audit the entirety of a C or C++ codebase. When I'm doing code reviews, you'd better believe I'm going to spend some extra time on any unsafe block I see to figure out if it's necessary and if so, if it's actually safe safe (with the default assumption for both of those being that they're not until I can convince myself otherwise).

Re: You gave me a u32. I gave you root. (io_uring ZCRX freelist LPE)

#73

Post by [deleted] »

josephg wrote: post #58
dvt wrote: post #53

Earlier quoted context omitted.

You actually kind of don't, I use like a zillion crates which have unsafe Rust in them and it's not like I'm sitting here reading every single line of their code. I like Rust for various reasons, but its memory safety is (imo) overstated, especially when doing low-level stuff.

Almost all rust (95%) is safe rust. You can opt out of array bounds checks with unsafe { array.get_unchecked(idx) } instead of just typing array[idx]. But I can't remember the last time I saw anyone actually do that in the wild. Its not common practice, even in most low level code. Rust is bounds checked by default. C is not. Defaults matter because, without a convincing reason, most people program in the default way…

[deleted]

Re: You gave me a u32. I gave you root. (io_uring ZCRX freelist LPE)

#74

Post by ryandrake »

Arcuru wrote: post #69
ryandrake wrote: post #49

Earlier quoted context omitted.

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?

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 ag…

Thanks for the reply. Pretty remarkable.

Re: You gave me a u32. I gave you root. (io_uring ZCRX freelist LPE)

#75

Post by 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

Re: You gave me a u32. I gave you root. (io_uring ZCRX freelist LPE)

#77

Post by saghm »

wizzwizz4 wrote: post #46
TheAdamist wrote: post #42

Earlier quoted context omitted.

If not static analysis what would ai tools be considered? They're operating off the same source code Also nice the onion reference by op.

It's a reference to Xe Iaso's blog (e.g. https://xeiaso.net/shitposts/no-way-to-prevent-this/CVE-2025... ), which is itself a reference to The Onion.

It's possible I had seen that blog post and not remembered! I was intending to reference the Onion though (and even googled to make sure I had the wording right), but seeing someone else make the same joke and forgetting is certainly something I would do

Re: You gave me a u32. I gave you root. (io_uring ZCRX freelist LPE)

#78

Post by skydhash »

saghm wrote: post #71
greiskul wrote: post #59

Earlier quoted context omitted.

And even if you do end up writing an unsafe block, that should be a massive flag that the code in said block should deserve extra comments on why it is safe, and extra unit tests on verifying that it does not blow up. How do you know the unsafe operation is safe? What are the preconditions the code block has? Write it down, review it, test it.

Exactly; I feel like a lot of people seem to misunderstand what Rust is trying to solve. It's fundamentally not trying to make unsafe code impossible; it's making the number of places you need to audit it a tiny fraction of your codebase compared to needing to audit the entirety of a C or C++ codebase. When I'm doing code reviews, you'd better believe I'm going to spend some extra time on any unsafe block I see to fi…

The thing is you can actually write quite good C code (see OpenBSD project). The power of C is that it's pragmatic. It lets you write code with you taking the full responsibility of being a responsible person. To err is human, but we developed a set of practices to handle this (by making sure the gun is unloaded and the safety is on before storing it to avoid putting holes in feet).

I like type checking and other compile time checks, but sometimes they feel very ceremonial. And all of them are inference based, so they still relies on the axiom being right and that the chain of rules is not broken somewhere. And in the end they are annotations, not the runtime algorithm.

Re: You gave me a u32. I gave you root. (io_uring ZCRX freelist LPE)

#79

Post by canucker2016 »

mikestorrent wrote: post #37
gpm wrote: post #36

Earlier quoted context omitted.

Like they said, "no way to prevent this" (kind of bug from happening again).

Static analysis and other tools can find this, but they're expensive; wonder what the kernel team has access to?

Coverity scans several open source projects for free. see https://scan.coverity.com/faq and https://scan.coverity.com/projects

see https://scan.coverity.com/projects/linux for the linux-specific scan results - you need to create an account to view the reported defects.

This past couple of weeks isn't a good look for them with the releases of defects found in Linux and Firefox.

Re: You gave me a u32. I gave you root. (io_uring ZCRX freelist LPE)

#80

Post by PlasmaPower »

delusional wrote: post #57
PlasmaPower wrote: post #32

Earlier quoted context omitted.

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

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
Post reply on HN