Read root-owned files as an unprivileged user. Pre-31e62c2ebbfd kernels (everything in stable as of 2026-05-14).
The bug
__ptrace_may_access() skips the dumpable check when task->mm == NULL. do_exit() runs exit_mm() before exit_files() — no mm, fds still there. pidfd_getfd(2) succeeds in that window when the caller’s uid matches the target’s.
Reported by Qualys, fixed by Linus 2026-05-14. Jann Horn flagged the FD-theft shape in October 2020. Six years.
Mitigation
Don’t run your PC if you don’t need it. Lock yourself in and look over your sholder …
Fix
Linus Torvalds himself patched the kernel: Making sure you're not a bot!. We have to see on when we patch our supported kernels …
What do you mean - I cannot think you mean the vulnerabilities disclosed the past weeks to be fake or inconclusive?
Could you please elaborate on your statement?
I know there has been references to various youtube stories on vulnerabilities, those are usually just created to attract viewers, which then generates advertisement revenues - it does nothing but to spread FUD (Fear Uncertainty Doubt) - those would count into the fake / inconclusive section.
That is - kind’a - inevitable - there will always be entities which will say anything - just to get attention.
Give me some credit for being able to read through the general bullshyte online.
No, I didn’t suggest that, at all – I thought the comment was clear – there is no disputing the benefit of discovery and disclosure of the recent vulnerabilities.
However, for the Community to reap those benefits, there have been many more instances of AI generated or assisted reports that were effectively noise; inconclusive; not useful at all.
There have been several articles illustrating this phenomenon of late – one that comes to mind is:
P.S: It’s rare that I watch anything on YouTube, and if I do, I’m afraid my taste doesn’t stray far from cats.
I assume he mean that curently several projects face a lot of reported vulnerabilities that have been found by AI. Unfortunately many turn out to be halluzinations or badly described and thus of no value but put a lot of work on the developers…
For example Nextcloud stopped the Bug Bounty program due to that…
Unfortunately the problem ther is at a different level and hard to fix by adjusting LlMs or AI..
Edit2: apparently it is getting better for at least some of them: at least according to the CURL developer
good use of ai ? this exploits a security-fail that was reported 6 years ago. seriously, it’s sad in the it-world that a lot of bug-reports are ignored by declaring them as less harmful and then ignoring it for years unless the bug impacts the it-world when no-one is even remembering it. this is a general problem in it wether it’s microsoft or linux.
we’ll see how it’s going on, i expect a horrible year by security-means. a short look on all the open, non-fixed linux-cve’s that have become ‘normal’ cause they are so called ‘less-critical’ is to worry. there’s no reason to downplay it as this example shows: a open-cve for 6 years now and some ai-code exploiting it. well it’s too simple and the workaround is disturbing
One could argue that bringing attention to many bugs or vulnerabilities (that otherwise might be swept under the rug, as historically so many have been) could be considered a positive outcome;
And that’s despite the apparent inconveniences of additional workloads such as experienced by Curl.
I couldn’t begin to estimate how many times searching for a resolution to a random issue ultimately led me to WONTFIX.
I spoke in general terms - and I spoke about real vulnerabilities.
I know that some ‘clever’ (note the quotation) people have create a lot noise with the public sources - reporting ‘their findings’ (note the quotation)
I am probably a dumb stupid moron - but I still don’t understand how your comment relate to mine.
agreed, there isn’t enough manpower avaiable to fix every issue but it’s another exploit at ssh. ssh is essential for every networking use, the primary domain of linux/unix and i wonder that there’s not much sense of responsibility is. it’s a difference when a bug brakes the use of the desktop (plasma, a well known candidate for declaring bugs to features) or a fundamental component like networking or access-rights is compromised.
Maybe a bit extreme? It requires an unprivileged account, right? So maybe restricting the users of the machine to trusted people and not installing new software until it gets fixed is enough?
Only chage should cause a bit of trouble for modern systems; ssh-keysign should not be used anywhere on a modern system.
It shouldn’t be. It’s not 2005 and we have hypervisor virtualization and container separation on Linux.
the bad: we will see many more PoC-ed vulnerability reports, practically zero days.
Regardless of responsible disclosure, someone with enough time on their hands (and a paid/stolen LLM access) can be reasonably assumed to generate a PoC based on a patch/description. This used to be a barrier before.
the good: more issues hidden in code will come to light
the good: like I said above, virtualization and containers
the bad: the group+user separation was supposed to work better (i.e. what we did 2 decades ago). Shifting the security boundary to another layer isn’t the full solution, but reminds me of the way browsers use sandboxes as additional security layers.
the bad: companies and other entities store more data about their users than ever before. How about we stop doing that? Today, the impact of unauthorized access is greater. Less data is good.
Maybe a bit extreme? It requires an unprivileged account, right? So maybe restricting the users of the machine to trusted people and not installing new software until it gets fixed is enough?
This can occur quite simply through a manipulated email or website … via web browser, email client or other applications and sources …
Are you sure? The exploit seems to require local arbitrary code execution to invoke certain syscalls in a certain way in some loop. And e-mail or websites shouldn’t be able to execute arbitrary code.
Well, e-mail shouldn’t be able to execute any code at all, and websites can execute JS or WebAssembly code inside a virtual machine (or interpreter) that is supposed to be well isolated from the rest of the system and without access to syscalls. So, those cannot be used to exploit this vulnerability, from my understanding.
Unless, of course, someone finds a browser exploit that escapes from the sandbox and allows arbitrary code execution. In such case it is possible to combine both exploits to gain root read access.
Someone please correct me if my understanding is wrong.
At the moment, I can’t say exactly, which impact disabling of ptrace could have, but regarding the kernel documentation it could be a problem for crash handlers from KDE, Firefox, Chromium or others. https://www.kernel.org/doc/Documentation/security/Yama.txt
