Another LPE has published: io_uring ZCRX freelist LPE

[-]

Megame50@reddit

In this case seems you need cap_net_admin in the same netns as a zcrx capable interface? And io_uring is commonly restricted by seccomp filters too. That's quite a bit less applicable than the copyfail vulns.

[-]

LordAlfredo@reddit (OP)

Yeah, as much publicity as these recent findings may have gotten there actually hasn't been a huge risk for most home users.

[-]

Vash63@reddit

Uhhh... Copyfail and Dirty frag are literally full root from any executable access. That's pretty applicable to home users.

[-]

LordAlfredo@reddit (OP)

Requiring an attacker already have machine access or a user run a program with it embedded.

[-]

Dangerous-Report8517@reddit

True but a lot easier to get than CAP_SYS_ADMIN, which is functionally already root access because of how much functionality is bundled into that capability (it's pretty much a catch-all permission these days). And it's not as hard to get unprivileged code execution on someone's machine as people think, particularly with supply chain attacks or even just tricking some people into running your vibe coded slop (yes this last case is largely PEBKAC but it's still one of the situations permissions are meant to mitigate, including sandboxing and containerisation which both make LPEs relevant even on single user systems, plus most people wind up in situations from time to time where they need to run some kind of obscure/less vetted code)

[-]

LordAlfredo@reddit (OP)

Yup. It's not exploitable for free but it's also not hard for the right circumstances to happen. The High 7.8 rating seems pretty spot-on.

[-]

hjake123@reddit

I mean, any Steam game update or browser sandbox escape can grant that access

[-]

CrazyKilla15@reddit

For most home users full root access from locally running code is irrelevant because the locally running code already has access to everything the user does, aka literally everything a user cares about, from browser cookies(all session tokens!) to sensitive local data, to any passwords stored in open SecretService(kwallet, gnome keyring, etc) vaults accessible over DBus, which are almost always opened on login; You dont need to enter your password everytime you start a browser do you? they usually store in a SecretService vault

also it is trivial, without any kernel LPE, to go from locally running to root. Simply alias sudo in .bashrc. Bonus points for su too, and even more bonus points for doing the equivalent for all the major shells(bash, fish, zsh).

Its doubtful most people would notice if sudo suddenly became a shell alias that captured what was typed and then forwarded it to sudo

[-]

_ahrs@reddit

Its doubtful most people would notice if sudo suddenly became a shell alias that captured what was typed and then forwarded it to sudo

Maybe run0 has a point about using Polkit. It's much harder to fake those desktop prompts.

[-]

elatllat@reddit

All those stories where AI can hack anything are getting more real.

[-]

InflateMyProstate@reddit

It’s not immediately clear via the article that this was found by AI. Plus, it seems this is not immediately exploitable since this is a new feature for io_using not yet in use by most distros:

Affected versions and requirements (from article):

Kernel: 6.15 – 6.19 without commit 770594e Config: CONFIG_IO_URING_ZCRX=y (not in most distro kernels yet) Hardware: Real ZCRX NIC: Mellanox ConnectX-6+, Intel E800 series, Netronome NFP, Broadcom BCM5750x, Google GVE

[-]

dnu-pdjdjdidndjs@reddit

This might not be ai, but i told gpt5.5 (because I have unlimited quota) to look for suspicious code and now I have a list of 50+ OOB writes at a rate of basically 1 new finding per minute

Most don't seem exploitable but almost all are clearly incorrect code in some capacity

So an expert could probably do this then go down the list and manually see which ones are potentially exploitable

[-]

OsgoodSlaughters@reddit

Your brain is pudding

[-]

dnu-pdjdjdidndjs@reddit

Would you change your mind if i sent a script that caused a kernel panic

[-]

silversurger@reddit

echo c | sudo tee /proc/sysrq-trigger

Am I an AI yet?

[-]

dnu-pdjdjdidndjs@reddit

sudo

Are you guys being dumb on purpose

[-]

silversurger@reddit

Are you?

Send that super cool script of yours then.

[-]

dnu-pdjdjdidndjs@reddit

Are you on linux mainline or next built after may 8th

[-]

silversurger@reddit

Mainline atm

[-]

dnu-pdjdjdidndjs@reddit

It has been dm'd to you sir, ensure thy kernel is from e98d21c170b01ddef366f023bbfcf6b31509fa83 and you have the rds/rds_tcp modules loaded and witness the root shell.

[-]

silversurger@reddit

So, you're saying that your method of causing a kernel panic still relies on having root access? Then I remain unimpressed.

(You still seem to miss that I was simply making a joke)

[-]

dnu-pdjdjdidndjs@reddit

You sound like an idiot

Instead of causing a kernel panic I sent you local privilege escalation from a bug found with ai, I'm starting to think that you might not know what you're talking about at all.

[-]

silversurger@reddit

You sound like an idiot

Yessir.

Instead of causing a kernel panic I sent you local privilege escalation from a bug found with ai

I noticed

I'm starting to think that you might not know what you're talking about at all

Maybe I am an AI after all then.

[-]

dnu-pdjdjdidndjs@reddit

its okay stay delusional

[-]

ThePoisonDoughnut@reddit

Please go read about John Curl's experiences in dealing with vibe security researchers making reports about such "vulnerabilities" that weren't actual vulnerabilities or were regarding code that didn't actually exist in curl/libcurl before you actually waste an expert's time with such "potential exploits."

[-]

CrazyKilla15@reddit

You should read "John Curl"(Daniel Stenberg)'s experiences, actually

https://www.linkedin.com/posts/danielstenberg_hackerone-activity-7446667043996725249-ZhEU

Over the last few months, we have stopped getting AI slop security reports in the #curl project. They're gone.

Instead we get an ever-increasing amount of really good security reports, almost all done with the help of AI.

They're submitted in a never-before seen frequency and put us under serious load.

I hear similar witness reports from fellow maintainers in many other Open Source projects.

Lots of these good reports are deemed "just bugs" and things we deem not having security properties.

We disclose all closed reports, so you can see this for yourself: [https://hackerone.com/curl/hacktivity?type=team]

[-]

dnu-pdjdjdidndjs@reddit

https://files.catbox.moe/70xtgr.png it's just not possible for ai to find real vulnerabilities

[-]

SethDusek5@reddit

It's worth pointing out that curl and Firefox developers now both agree AI bug reports have gone from slop to actually useful in a matter of months

[-]

ThePoisonDoughnut@reddit

There's no way that doesn't come with the caveat that it applies when these tools are in the hands of already very skilled security researchers, and not people who are just telling chatgpt to go find bugs in some code.

[-]

_ahrs@reddit

A VERY important caveat. The bug reports Claude found in Firefox were handled by an experienced team of researchers at Anthropic. The tool didn't just find vulnerabilities out of thin air, it worked in tandem alongside these researchers who carefully prompted and analysed the reports before verifying them and then doing responsible disclosure to Mozilla.

Absolutely not a case of:

Me: Find me vulnerabilities

ChatGPT: Here's a list of 50+ OOB write issues I found

[-]

dnu-pdjdjdidndjs@reddit

https://files.catbox.moe/70xtgr.png I am an expert but I only needed to help it write the actual exploit, the vulnerability finding part was entirely autonomous

[-]

dnu-pdjdjdidndjs@reddit

genuinely not even worth having these conversations with people who aren't even following what's happening or cant read what I said

[-]

dnu-pdjdjdidndjs@reddit

go read the update numb nuts

[-]

Wonderful-Citron-678@reddit

Software has always been super buggy, this is just extreme fuzzing basically. So things get fixed and improve with time.

[-]

knasman@reddit

The whole thing is a bunch of ai hallucinations, there’s absolutely nothing there. The author admitted as much and said he’d change it. Of course he didn’t.

The fact that you need to be root to use this exploit should tell you something. But hard to miss when buried in llm bs. And the fact that the commit referencing as fixing it is entirely wrong. But hey, nobody reads anything anymore, even a one liner debug statement that even has a clear commit message.

https://x.com/axboe/status/2052792260316852705?s=46

[-]

knasman@reddit

At least the author took it down now, as he promised to do. Much easier to spread false news that it is for people to have critical reading skills - or apparently for a blog writer to do any real thinking or analysis of his own.

[-]

tetyys@reddit

Fix: commit 770594e (not yet in any stable branch at time of writing)

and this was disclosed because...?

[-]

Zoddo98@reddit

Because the kernel security team has no established process for coordinated/private patching of security issues.

Security patches are handled like any other patch: on the public mailing lists, and then on the public git repositories all the way until it hits torvalds' repo.

IMO, they should have a process for high impact security issues to keep the patches private until the very last moment (not using the standard process, and merging the patch directly in torvalds' repo right before a new version releases).

[-]

CrazyKilla15@reddit

Because the kernel security team has no established process for coordinated/private patching of security issues.

This seems a very bad faith interpretation. They allow, at reporters request, a up to a 7 day embargo, or 14 in exceptional circumstances. The openwall linux-distros list is the same.

https://docs.kernel.org/process/security-bugs.html#disclosure-and-embargoed-information "The only valid reason for deferring the publication of a fix is to accommodate the logistics of QA and large scale rollouts which require release coordination."

Additionally, just because you disagree with their stance on the usefulness of embargos and the legitimacy of signaling out "security bugs" from "normal memory and logic bugs" doesnt mean they dont have a process.

[-]

knasman@reddit

Maybe check that actual commit. See my other comment in this thread, the entire “exploit” or report is bogus.

[-]

eggbart_forgetfulsea@reddit

I personally don't like embargoes. I don't think they work. That means that I want to fix things asap. But that also means that there is never a time when you can "let people know", except when it's not an issue any more, at which point there is no point in letting people know any more.

So I personally consider security bugs to be just "normal bugs". I don't cover them up, but I also don't have any reason what-so-ever to think it's a good idea to track them and announce them as something special.

https://lore.kernel.org/lkml/alpine.LFD.1.10.0807141924020.3017@woody.linux-foundation.org/

[-]

QliXeD@reddit

We got in an era of vibe-disclosing?

[-]

Conercao@reddit

As far as I know, RHEL treats io_uring as preview stuff and it's disabled by default. The Oracle Linux documentation I've seen makes no such distinction