Get the top HN stories in your inbox every day.
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?
PlasmaPower
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
I don't think namepsace CAP_SYS_ADMIM grants you access to write non namespaces sysctls like modprobe_path
PlasmaPower
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
Right. `CAP_SYS_ADMIN` is for all intents and purposes equivalent to root.
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.
spindump8930
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
> 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
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
In some sense, I wonder if non-open-source is "safer" since LLMs can't mass scan the code for exploits.
overboard2
Maybe for a while, but there's nothing stopping LLMs from examining disassembler output.
calebhwin
It's actually the perfect evergreen content to discuss on HN in an age where so much else is AI generated.
majorchord
AI is happening.
cachius
In each recent case?
gordonhart
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.
raverbashing
I wonder where are the Rust naysayers hiding now
C code is broken - period
gilrain
Automated vulnerability discovery via LLM.
ryandrake
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
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.
huflungdung
[dead]
pixl97
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
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
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.
sherr
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.
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...
javascripthater
big ups pimp
kro
CAP_NET/SYS_ADMIN is required for this. So this would be "not as bad" as the others.
kam
Also "The page pool is only created on a real ZCRX-capable NIC (mlx5 ConnectX-6+, Intel E800, NFP)"
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...
pocksuppet
Aren't CF2 and DF the same exploit?
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).
otterley
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
super curious on this one as well, last I heard they've been enabling it slowly
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.
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.
saghm
[flagged]
musicale
> "No way to prevent this", Says Only Language Where This Regularly Happens
clang -fbounds-safety ...
dataflow
NOTE: This is a design document and the feature is not available for users yet.
dvt
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.
gpm
Like they said, "no way to prevent this" (kind of bug from happening again).
mikestorrent
Static analysis and other tools can find this, but they're expensive; wonder what the kernel team has access to?
ellieh
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
dvt
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.
amluto
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.
skullone
except nearly everyone uses unsafe rust
Rygian
That's not prevention. That's remediation.
undefined
slopinthebag
Surely nobody could create a better language in 50 years. Surely we can't fix these issues.
themafia
And you see a lot of other languages being used to create operating systems with complicated multiprocessor and locking semantics?
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?
Get the top HN stories in your inbox every day.
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