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.
> “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?
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.
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...
CAP_NET/SYS_ADMIN is required for this. So this would be "not as bad" as the others.
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).
Do most servers need this? Or can most of us 'sysctl -w kernel.io_uring_disabled=2 ' ?
What’s our prior for p(doom) today…?
Another one.
Linux is falling apart faster than it can assign these CVEs.
> No bounds check. free_count is incremented before the write, and the write uses the pre-increment value as the index. When free_count == num_niovs at entry, the write goes to freelist[num_niovs], one slot past the end.
"No way to prevent this", Says Only Language Where This Regularly Happens