If you check the latest Linux kernel releases on kernel.org, you’ll see that 7.0.8 and other recent versions have a changelog with a single entry, a bug-fix signed off just last Wednesday.
Very greatly summarised, a process monitoring misfeature in the ptrace system, where ptrace stands for “process trace,” just got patched.
A function called ptrace_may_access() is used to decide whether process A is allowed to snoop on process B, with the noble intention of preventing an unprivileged program from grabbing a “core dump” from a privileged program, and then scraping its memory image to steal secrets such as passwords or cryptographic keys.
The word core is a historical jargon term for RAM, based on old-school ferrite memory technology that died out in the late 1960s and early 1970s. We’ve kept the word alive because it’s a short, cool term, like still saying that we dial a phone, or film a video. For a splendid picture of what core memory looked like, see here.
The security hole, it seems, is that while a privileged process is shutting down, an unprivileged attacker can nevertheless grab dangerous information about it, because the test to see whether access should be granted is based on whether the privileged program still has memory assigned to it.
After all, a program with no RAM, you might reasonably expect, doesn’t really exist – there would be nowhere for its code or its data to live, and there would be no data left to scrape.
But a security researcher going by SiCK, of the 0xdeadbeefnetwork, found otherwise.
0xDEADBEEF, in case you are wondering, is what passes for coding humor – a 32-bit hexadecimal number often used by debuggers to tag as-yet unused or recently returned memory blocks so they can easily be monitored for unexpected reads or writes.
Grabbing sensitive files
Imagine that you run a privileged utility (in Linux terminology, a program that is setuid-root) that is authorized to access super-secret files, such as SSH keys or the /etc/shadow database of password hashes, and wait for or force it to terminate.
At this point, there is a short window of opportunity (a race condition, in the jargon), before the program has truly exited for good, during which its memory has already been released, and thus it passes the ptrace_may_access() test․․․
․․but its open files have not yet been closed.
During this race window, an unprivileged program can therefore bypass the “you are not allowed to access this privileged process” check – the process is deemed safe to examine because it has no memory left to scrape.
But a rogue program can still scrape the file descriptors for the privileged program’s as-yet-unclosed files, and read out their contents.
One of SiCK’s proof-of-concept (PoC) exploit programs shows how to misuse the commonly-installed ssh-keysign program, which a regular user can run.
This utility is a setuid-root program, because it needs to read in root-only SSH private key files to do its job.
After a few tries to catch the ssh-keysign program in the right race window, the exploit can extract various security-critical cryptographic keys used to prove a computer’s identity when it logs into other online services, by grabbing the contents of files such as /etc/ssh/ssh_host_rsa_key and ssh_host_ed25519_key.
The servers protected from rogue access by these private keys could include services such as online code repositories, blogs, software download sites, cloud backups, and more.
A second PoC exploit uses the chage program, used to access or change password expiry settings, a utility found on most Linux systems whether their sysadmins enforce “password aging” or not.
A regular user can run this utility to remind themselves when their own password next expires; the PoC does just that, but also exploits the race condition to read out the system-only file /etc/shadow.
This file contains password hashes for everyone on the system, including users with root, or admin-level, access.
Although this doesn’t directly expose any passwords, it does provide input data for offline password cracking tools to have a go at recovering passwords for other users and system services on the computer.
What to do?
Patch your kernel as soon as you can.
Check with your distro provider to ensure they have applied the patch to their kernel packages.
Why not ask how SolCyber can help you do cybersecurity in the most human-friendly way? Don’t get stuck behind an ever-expanding convoy of security tools that leave you at the whim of policies and procedures that are dictated by the tools, even though they don’t suit your IT team, your colleagues, or your customers!
More About Duck
Paul Ducklin is a respected expert with more than 30 years of experience as a programmer, reverser, researcher and educator in the cybersecurity industry. Duck, as he is known, is also a globally respected writer, presenter and podcaster with an unmatched knack for explaining even the most complex technical issues in plain English. Read, learn, enjoy!
Paul Ducklin
05/16/2026
Share this article:
Table of contents:
The world doesn’t need another traditional MSSP or MDR or XDR.
We start with identity and end with transparency — protecting where attacks begin and keeping you informed, with as much visibility as you want. No black boxes, just clear, expert-driven security.
We use cookies to ensure that we give you the best experience on our website. If you continue to use this site we will assume that you are happy with it. Privacy policy
I am interested in SolCyber DPM++
I am interested in SolCyber XDR++™
I am interested in SolCyber MDR++™
I am interested in SolCyber Extended Coverage™
I am interested in SolCyber Foundational Coverage™