Another vulnerability via ptrace_may_access bypass. Patch already accepted upstream.

[-]

friendlyreminder_@reddit

This one is not a privilege escalation per se but it allows the exploit to read root access protected files. So you can access things like the user and root password hashes, and if the passwords are weak crack them. Then you get root access.

I don't know how many other root access protected files there are out there of security concern, but as usual these exploits can sometimes do more than it seems at first glance.

[-]

aioeu@reddit

This one is not a privilege escalation per se but it allows the exploit to read root access protected files.

Specifically, it requires a root-owned, set-user-ID executable that opens a file, and then drops its persona back to the original user (who would be the "attacker" in this scenario).

Normally a process that has gone through these steps is not "dumpable". That means you can't use ptrace on it, so you can't attach to it with strace or a debugger such as GDB, nor can you read various things in /proc about the process. This is despite the fact that it's now running as the original user again — the fact it went through the whole set-user-ID rigmarole means that it must still be treated as a privileged process for these purposes.

The bug in the kernel is that there is a very small time window, while the process is exiting, that the process becomes dumpable again. In particular, this happens before the process's file descriptors are cleaned up. It is possible to gain access to the process's file descriptors through one of the kernel's syscalls that are gated on this dumpability, which means it is possible to access the file referred to by that file descriptor. Remember, this file was opened before the process dropped its persona!

[-]

CrazyKilla15@reddit

Also, fun fact: the existence of the underlying flaw has been known about for almost six years. It might have required the pidfd stuff to actually land before it became a vulnerability though.

....wow.

[-]

aioeu@reddit

The thing is, that on its own isn't a very big vulnerability. It might have let some things become readable under /proc/$pid, but since the mm had been dropped there is essentially no sensitive information left there.

It needed something additional: a way to dup a file descriptor out of the exiting process. pidfd_getfd provided that.

[-]

CrazyKilla15@reddit

I think that was added in 2020 too, but I haven't looked at the exact timing.

It was, per the man page in Linux 5.6, which released March 29th, 2020.

[-]

aioeu@reddit

Ah, earlier in the year.

[-]

CrazyKilla15@reddit

oops that was fast, I made some ninja edits

[-]

glotzerhotze@reddit

Thank you!

[-]

Lower-Limit3695@reddit

An attacker could steal the ssh host key . This would allow an attacker to masquerade as the host the key was stolen from.

[-]

marcusaurelius_phd@reddit

There isn't much you can do with that.

[-]

LordAlfredo@reddit (OP)

That is one of the most important things an attacker wants for spoofing.

[-]

foobar93@reddit

MITM Attacks?

[-]

CrazyKilla15@reddit

Mitigation from oss-security

Excellent question, thank you very much! We have just now tried, and setting /proc/sys/kernel/yama/ptrace_scope to 2 (admin-only attach) or 3 (no attach) does in fact protect against all the exploits that we know of (but in theory at least other exploitation methods might exist).

https://www.openwall.com/lists/oss-security/2026/05/15/8

[-]

LordAlfredo@reddit (OP)

Here's the patch commit

Expect yet another kernel update on your distro with this soon.

[-]

eggbart_forgetfulsea@reddit

Torvalds really treats users as morons with these kind of commit messages.

[-]

LordAlfredo@reddit (OP)

This was a pretty reasonable commit message. It explained the background, the problem, and the solution without implying anything about users/usage other than "this wasn't an intended behavior"

[-]

hypespud@reddit

Isn't it a good thing to get patches like this?

I feel like it this wasn't open source we would not get this information nearly as rapidly as a closed source system

Is there a role for AI LLM to review code more rapidly and more regularly to identify software security issues too as a read-only type of situation also? I feel like this is one of the ideal uses of AI to help with software development

[-]

LordAlfredo@reddit (OP)

Yes, it's a good thing.

This was originally discovered and mentioned in LKML 6 years ago, I'm curious what else will pop up from LLMs combing the archives.

[-]

forumcontributer@reddit

I am tired boss.

[-]

Far_Comb4683@reddit

Could not have said it any better. The future looks bleak

[-]

TRKlausss@reddit

Don’t you have automatic Security Updates through your distro??

[-]

JockstrapCummies@reddit

Me with Livepatch pushing kernel security fixes without even needing to reboot: 😎🍹

[-]

Sjoerd93@reddit

So if this recent influx of vulnerabilities is indeed from LLM-based vulnerability research. Maybe it's time for some of the biggest benificieries of the Linux-code to throw in some effort?

Surely e.g. Microsoft, which is one of the biggest users of Linux and one of the biggest drivers of LLM-usage, should reasonably spend some of their fortune to prevent maintainer-burnout in the kernel-space?

[-]

Pramaxis@reddit

Have you read the study from the linux foundation about the donation habits from tech comps.? MS donated less to FOSS, since '95 than the EU did, just last year.

[-]

Formal-Bread9422@reddit

Wait until you learn about intentional backdoors.

[-]

rebellioninmypants@reddit

Nah they too busy pushing out 1 million lines of code per month per engineer.

[-]

shaumux@reddit

It's time code gets treated as something that needs quality, for the longest time now the managers just assumed code quality to be a myth or something non-essential, we need to be more rigorous on that and treating it like an actual science and engineering discipline.

[-]

LordAlfredo@reddit (OP)

The patch itself