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

https://ze3tar.github.io/post-zcrx.html

by MrBruh • 3 months ago

215 144 3 months ago

ze3tar.github.io

rvz• 3 months ago

Another one.

Linux is falling apart faster than it can assign these CVEs.

EGreg• 3 months ago

How's BSD doing? How about Amazon Linux?

cachius2• 3 months ago

And Windows?

yjftsjthsd-h2• 3 months ago

Amazon Linux is a Linux distro? Though, yes, I would like to know how the BSDs are doing.

toast0• 3 months ago

FreeBSD is getting piles of security updates lately too. Not sure about the other BSDs.

maven29• 3 months ago

perhaps this will lead to better AppArmor and SELinux defaults?

ChocolateGod• 3 months ago

People will just turn SELinux off rather than have to go through the horrible tooling when it breaks a regular use case.

hn92726819• 3 months ago

Falling apart? You mean getting stronger? Every single one of these is an existing hole being patched. It isn't making new holes

Gigachad2• 3 months ago

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.

tgv• 2 months ago

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.

pjmlp6• 2 months ago

I remember when people used to joke with Windows security and something like that would never happen on Linux, well..

gordonhart2• 3 months ago

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.

staticassertion2• 3 months 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).

otterley2• 3 months 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• 3 months ago

super curious on this one as well, last I heard they've been enabling it slowly

m348e9122• 2 months ago

I was reading similar comments about AF_ALG which lead to the copy-fail exploit. Could we see a trend of moving away from less used tools/modules that expand the vulnerability footprint?

tetha• 2 months ago

We at work are currently going through the kernel modules available on Debian by default and deactivating things, yes.

And sorry, but I am ... frustrated by this. Why do my Debian 11 servers (currently upgrading, yes) have support for phone infrastructure from the 90s (ATM), or really obscure file systems like "Andrews File System" or support to run IP across amateur radios (AX.25) by default? We recently joked that we should start a pot you add a euro to whenever you find ancient discontinued tech you never heard about our systems support so we can have some nice dinner after this.

I do understand that going full Gentoo or Arch as a generally available distro is not feasible. I am also personally intimidated by compiling my own kernel with just what we need. But the amount of strange ancient things supported by default is also quite ridiculous.

staticassertion2• 2 months ago

io-uring is in a different league imo. I'd say that it's second only to user namespaces in terms of attack surface.

That said, putting stuff in a docker container is kinda a light lift that cuts a bunch of attack surface.

rishabhaiover• 3 months 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.

majorchord• 3 months ago

AI is happening.

cachius2• 3 months ago

In each recent case?

halJordan• 2 months ago

I was promised that ai was just a stochastic parrot

spindump8930• 3 months 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).

gilrain• 3 months ago

Automated vulnerability discovery via LLM.

pixl97• 3 months 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.

ryandrake2• 3 months 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?

john_strinlai• 3 months 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.

NitpickLawyer• 3 months 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.

themafia2• 3 months ago

Perhaps it was the prior quiescent period that was the anomaly.

sva_• 2 months ago

A mix of AI and hybrid warfare.

zipy124• 2 months ago

Yes I think people forget that cyber-war between West and East is very active, with a significant amount of attacks being committed by nation states or state-sponsored groups.

Aurornis• 2 months ago

Warfare does not look like releasing neatly documented vulnerability reports to the public.

elija• 2 months ago

In some sense, I wonder if non-open-source is "safer" since LLMs can't mass scan the code for exploits.

overboard2• 2 months ago

Maybe for a while, but there's nothing stopping LLMs from examining disassembler output.

IcePic• 2 months ago

If they don't get scanned, then they also don't get fixed, so if they have the same amount of holes, they will stay vulnerable for longer.

calebhwin• 2 months ago

It's actually the perfect evergreen content to discuss on HN in an age where so much else is AI generated.

jdub• 2 months ago

... there's also a bit of a frequency illusion factor.

raverbashing• 2 months ago

I wonder where are the Rust naysayers hiding now

C code is broken - period

dgellow• 2 months ago

I'm not sure it is too unusual to be honest. I feel that we have that type of content from time to time

baq• 3 months ago

What’s our prior for p(doom) today…?

FriedFishes2• 3 months 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

kro3• 3 months ago

CAP_NET/SYS_ADMIN is required for this. So this would be "not as bad" as the others.

t0mas88• 3 months ago

It could work for container escape?

kro3• 2 months ago

Containers, even with root user, are often stripped of these capabilities unless --privileged

kam• 3 months ago

Also "The page pool is only created on a real ZCRX-capable NIC (mlx5 ConnectX-6+, Intel E800, NFP)"

nyrikki3• 2 months ago

It is a minimal improvement due to the introduction of user namespaces and the fallout from local team convenience for Docker and thus OCI.

It is very important that you realize that any capability is a slice of superuser privileges, and there are no implicit protections, only explicit additional constraints that restrict it in reference to root.

Look at the bounding set for a normal user on a fresh install of rhel/debian based systems:

     $ grep ^Cap /proc/$$/status
     CapInh: 0000000000000000
     CapPrm: 0000000000000000
     CapEff: 0000000000000000
     CapBnd: 000001ffffffffff

Note how trivial it is to gain all of those capabilities:

    $ podman unshare
    # grep ^Cap /proc/$$/status
    CapInh: 0000000000000000
    CapPrm: 000001ffffffffff
    CapEff: 000001ffffffffff
    CapBnd: 000001ffffffffff
    CapAmb: 0000000000000000
    # capsh --decode=000001ffffffffff
    0x000001ffffffffff=cap_chown,cap_dac_override,cap_dac_read_search,cap_fowner,cap_fsetid,cap_kill,cap_setgid,cap_setuid,cap_setpcap,cap_linux_immutable,cap_net_bind_service,cap_net_broadcast,cap_net_admin,cap_net_raw,cap_ipc_lock,cap_ipc_owner,cap_sys_module,cap_sys_rawio,cap_sys_chroot,cap_sys_ptrace,cap_sys_pacct,cap_sys_admin,cap_sys_boot,cap_sys_nice,cap_sys_resource,cap_sys_time,cap_sys_tty_config,cap_mknod,cap_lease,cap_audit_write,cap_audit_control,cap_setfcap,cap_mac_override,cap_mac_admin,cap_syslog,cap_wake_alarm,cap_block_suspend,cap_audit_read,cap_perfmon,cap_bpf,cap_checkpoint_restore

The capabilities(7)[0] man page will help you with all of those.

But capabilities are just a thread local segmentation, which grants superuser or root rights in a vertical segmented fashion.

True, if a mechanism chooses to do additional tests based on credentials(7)[1], you can run with those elevated privileges in a lower bound, but that requires implicit coding.

Add in that LSMs are suffering from both resources and upstream teams that won't provide guidance or are challenging to work with, and there are literally a hundred commands to either abuse or just ld_preload to get unrestricted userns, allowing you to get around basic controls on clone()/unshare() that may be implemented.

      $ grep -ir "userns," /etc/apparmor.d/ | wc -l
      100

With apparmor every single browser (firefox,chrome,msedge,etc...) as well as busybox, slack, steam, visual studio, ... all have the unrestricted user namespaces and the ability to gain the FULL set of capabilities in the bounding set.

If you run `busybox` on a debian system, note how it has nsenter and unshare, so you can't mask those and yet busybox itself is unconstrained with elevated privlages.

The TL;DR point being, don't assume that any capability() is in itself a gate, as there are so many ways even for the user nobody to gain them.

[0] https://man7.org/linux/man-pages/man7/capabilities.7.html [1] https://man7.org/linux/man-pages/man7/credentials.7.html

cyphar2• 2 months ago

1. The privilege check in question here is capable(CAP_NET_ADMIN), so it doesn't work in user namespaces.

2. Most sandboxes (including Docker and Podman) disable creating unprivileged user namespaces inside them via seccomp. In this mode, you end up with a more secure setup than requiring a privileged process to spawn containers (for one, it massively reduces the risk of confused deputy attacks against container runtimes). You can also restrict it with ucounts (as rough of a system as that is).

3. The kernel provides this facility and the feature was added back in early 2013 (before Docker existed and long before they added user namespace support, let alone rooless containers), so I don't understand why you think this is somehow the fault of OCI? We're just making something useful out of existing kernel infrastructure. Folks have asked the kernel to provide a knob to disable unprivileged user namespaces but the maintainer has refused to do so for years (the best you get is ucounts and seccomp). I would also prefer to have such a knob (or even adding a separate ucount with configurable per-user limits) but it's not up to me.

(Disclaimer: I implemented rootless containers for runc back in the day and work on OCI, so I do have some bias here.)

stonegray• 3 months 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?

pizzalife• 3 months ago

Right. `CAP_SYS_ADMIN` is for all intents and purposes equivalent to root.

throwaway7356• 2 months ago

No, not since namespacing came around.

PlasmaPower4• 3 months 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• 3 months ago

I don't think namepsace CAP_SYS_ADMIM grants you access to write non namespaces sysctls like modprobe_path

saghm8• 3 months ago

[flagged]

dvt3• 3 months ago

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• 3 months ago

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

Rygian• 3 months ago

That's not prevention. That's remediation.

amluto2• 3 months ago

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.

ellieh• 3 months ago

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

musicale2• 3 months ago

"No way to prevent this", Says Only Language Where This Regularly Happens

   clang -fbounds-safety ...

also see lib0xc etc.: https://news.ycombinator.com/item?id=47978834

dataflow• 2 months ago

NOTE: This is a design document and the feature is not available for users yet.

https://clang.llvm.org/docs/BoundsSafety.html

themafia2• 3 months ago

And you see a lot of other languages being used to create operating systems with complicated multiprocessor and locking semantics?

saghm8• 2 months ago

It's been almost half as long since the operating system under discussion as it has been since the creation of the language under the discussion, and there haven't really been any new mainstream operating systems created since then. I don't think it's nearly as obvious as you're implying that if there were a new operating system created today that C would be a good choice for it. If we're talking about non-mainstream OS's, then I'd argue there's already more than enough evidence that safer languages than C are more than capable of it[1]

[1] https://hubris.oxide.computer/

slopinthebag• 2 months ago

Surely nobody could create a better language in 50 years. Surely we can't fix these issues.

SubiculumCode• 3 months ago

Do most servers need this? Or can most of us 'sysctl -w kernel.io_uring_disabled=2 ' ?

shorden• 3 months 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.

ctoth• 3 months ago

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• 3 months 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.

pamcake• 3 months 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• 2 months ago

big ups pimp

csmantle• 2 months ago

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• 2 months ago

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).

himata41132• 2 months ago

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.

pjmlp6• 2 months ago

Yes on Android, iDevices, macOS, Windows (UWP, Win32 boxing), Qube OS, but it remains a controversial topic in GNU/Linux land.

soupbowl• 2 months ago

I am pretty sure that Flatpak does 'not' do a good job when it comes to sandboxing, maybe one day.

himata41132• 2 months ago

does it not? I know dbus is a problem that they can't really do much about except disabling it and wayland solved display based escalation.

somebudyelse• 2 months 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• 2 months ago

Aren't CF2 and DF the same exploit?

__bjoernd2• 2 months ago

DirtyFrag and CooyFail2 are two exploits of the same bug.

This one is a level less severe.

teo_zero• 2 months ago

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?

__bjoernd2• 2 months ago

If you want to claim the fame of being the first with an exploit, responsible disclosure only gets in the way. Same as the CF2 author.

sherr• 2 months 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.

danborn26• 2 months ago

It is wild how many vulnerabilities are still popping up in io_uring. The attack surface is just so large.

varispeed• 2 months ago

Security services must be sobbing right now as all the juicy exploits they've been using for years will be patched.

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

Related Stories