You gave me a u32. I gave you root. (io_uring ZCRX freelist LPE)
2 points by dzwdz
2 points by dzwdz
second edit: this is a nothingburger, see this email from the author
At this point I’m not claiming a new unfixed LPE or a separate CVE. [...] I’ll update the blog post to reflect that more clearly so it does not misrepresent the current understanding of the issue.
Leaving the story up so it doesn't get reposted without this explanation.
Not yet sure if this is legit, supposedly it's yet another LPE. We seem to be bouncing back and forth between slopped up disclosures and normal ones.
This one doesn't come with a suggested workaround! What a fucking dick.
edit:
Affected: Linux 6.15 – 6.19, CONFIG_IO_URING_ZCRX=y, real ZCRX NIC (mlx5/ice/nfp), CAP_NET_ADMIN.
What even is a "real ZCRX NIC"? You'd think that they'd care to explain that. Earlier in the TL;DR they define ZCRX as an io_uring subsystem. How can ZCRX then also be a property of hardware?
Debian stable is on 6.12, so in theory it should be safe, but considering this disclosure was generated by AI the author probably didn't verify if this version range actually checks out. The en-dash doesn't spark confidence.
This is also being discussed on oss-sec. Someone submited some slop there to request a CVE for this (?) vulnerability, that they didn't find, but that they noticed being fixed in a recent commit. Solar Designer responded:
I only skimmed, but as far as I can tell Mohamed isn't the original finder of this issue and the report and PoCs are AI-generated, which could be why Mohamed is not communicating further. It's becoming a trend - someone sends AI-generated report and doesn't communicate. Which doesn't mean the report is useless, but it does complicate its handling.
Meanwhile, it looks like there's a blog post (by someone else? I am confused) on exploitation of this issue, with exploit files attached: [the one linked in this story]
Jens Axboe calls out this fragment from this blogpost:
This sysctl entry writes directly into modprobe_path in kernel memory and is writable with CAP_SYS_ADMIN, which we already have via CAP_NET_ADMIN on container configurations that grant both.
This makes no sense. CAP_NET_ADMIN doesn't grant you CAP_SYS_ADMIN.
IIRC you can get CAP_NET_ADMIN in an unprivileged namespace? So if the underlying bug only required that capability, this is probably still cause to worry. Who fucking knows. As pointed out on HN, you get CAP_SYS_ADMIN in unprivileged namespaces too.
Huh?
Once we have the address of modprobe_path (from KASLR step above), we write our script path via /proc/sys/kernel/modprobe
So if you can simply write an arbitrary path into /proc/sys/kernel/modprobe by construction, then why do you need the address of a global (or, indeed, the entire vulnerability thing)? Either I am fundamentally missing something, or the writeup makes no sense. I hope it's the former.
The PoC files make no sense either — there is no attempt to write to modprobe_path, neither there is an attempt to actually defeat KASLR and get the address of the global in any situation which is actually unprivileged.