HN Explorer

37 comments

[ 2.6 ms ] story [ 64.6 ms ] thread
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).
m348e912
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?
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.
elija
In some sense, I wonder if non-open-source is "safer" since LLMs can't mass scan the code for exploits.
calebhwin
It's actually the perfect evergreen content to discuss on HN in an age where so much else is AI generated.
jdub
... there's also a bit of a frequency illusion factor.
raverbashing
I wonder where are the Rust naysayers hiding now

C code is broken - period

dgellow
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
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.
nyrikki
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

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

nyrikki
1) the various projects refused even simple requests like allowing the admin to disable the —privileged flag, in the rootfull days. 2) The choice to break out CRI will zero authorization or mutations at the CRI level, while understandable to the containerd teams needs, exposed every other runtime to an unprotected alternative communication path. 3) The OCI groups refusal to provide guidance to LSM maintainers as to minimal configurations, while also handling the responsibilities of seccomp profiles to end users means only actively attacked vectors are protected and it becomes impossible for normal users to operate safely. 4) under the UNIX model it is the caller to clone/fork/unshare that must drop privileges. 5) This model was set in concrete by the OCI standards and now suffers from the frozen caveman pattern.

The capable()[0] syscall operates as one would expect for granting superior capabilities, and while the work to expand the isolation is something I am sure you are familiar with, you probably also realize that the number of entries in a default user also expanded just to support user namespaces.

But to be clear, the choices that docker/oci made are understandable from a local greedy choice perspective, it complicates the entire user space.

K8s mutating inlet controllers are a symptom of those choices.

Had a CRI contained a bounding set, enforced at a system level, especially with guidance and tools for users to use a minimal set, which they could expand on easily we would be in a better spot.

But as other projects cannot provide meaningful protections that cannot be simply bypassed by calling privileged CRIs it is also a barrier to convincing them to do the same.

Really there is a larger problem that OCI could be the leader on, but they are the ‘killer app’ and refuse to do so.

The bounding set for user capabilities is driven by containers, and while namespaces are not and never have been a security feature, this blocks their ability to have a strong security posture.

To be clear, expecting every end user to write minimal seccomp profiles is unrealistic, especially when docker prevents devs from accessing the local machine to discover what is happening. I think podman is the only machine that allows that by default.

Basically while simplifying moby/containerd/CRI is an understandable choice, the refusal to address the costs of that local optim has fallout

[0] https://elixir.bootlin.com/linux/v7.0.5/source/kernel/capabi...

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?

saghm
[flagged]
slopinthebag
Surely nobody could create a better language in 50 years. Surely we can't fix these issues.
SubiculumCode
Do most servers need this? Or can most of us 'sysctl -w kernel.io_uring_disabled=2 ' ?
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.

[deleted]
(comment deleted)
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.

pjmlp
Yes on Android, iDevices, macOS, Windows (UWP, Win32 boxing), Qube OS, but it remains a controversial topic in GNU/Linux land.
soupbowl
I am pretty sure that Flatpak does 'not' do a good job when it comes to sandboxing, maybe one day.
himata4113
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.
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?

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.
danborn26
It is wild how many vulnerabilities are still popping up in io_uring. The attack surface is just so large.
varispeed
Security services must be sobbing right now as all the juicy exploits they've been using for years will be patched.