New Linux Kernel Flaw “ssh-keysign-pwn” Exposes Root Access on Major Distros

The Short Version

What: A Linux local privilege escalation in __ptrace_may_access(), informally called ssh-keysign-pwn (or chage_pwn after the headline PoC). No CVE has been assigned at the time of publication.

Impact: A public proof of concept reliably elevates an unprivileged local user to root by racing SUID binaries through that window: chage to leak /etc/shadow, ssh-keysign to leak SSH host private keys.

Status: The upstream fix (commit 31e62c2) landed in the same window as the public disclosure on oss-security. No CVE assigned yet, Qualys advisory not yet published, no CVSS score yet. KernelCare has shipped rebootless patches for Ubuntu 22.04 (Jammy), Debian 11 (in ePortal), EL9 family (in test + main feeds), RHEL 8/Rocky Linux 8 (in test feed).

Severity: Local vector, no privileges required, no user interaction, no special configuration. The public PoC works out of the box on Debian 11/12/13, Ubuntu 22.04/24.04/26.04, Arch, Raspberry Pi OS Bookworm, and the EL9 and EL10 families. EL8 and Ubuntu 20.04 are vulnerable but need an adapted PoC. EL7 on the 3.10 kernel is not affected.

Why this matters: Because the exploit targets common SUID binaries and requires no privileges or user interaction, vulnerable multi-user Linux systems should be treated as immediately at risk.

Do this now: Tighten Yama ptrace_scope on servers (one sysctl, reversible). KernelCare customers should watch for the testing-feed release. Mitigation commands and rebootless patch deployment instructions are below.

The Long Version

A Linux kernel root exploit hit GitHub this morning with no CVE ID attached, no advisory from the researcher who discovered the flaw, and a public PoC that works on a stock Debian or Ubuntu box. The bug is in __ptrace_may_access(). The fix landed upstream in the same window – good news, except nobody outside the distribution kernel teams will have it for days.

Here’s the sharper detail in the timeline. Jann Horn proposed an equivalent fix to this bug in 2020. It didn’t merge. The root cause sat in every stable kernel branch for five years until a Qualys researcher rediscovered it and a second researcher dropped two working exploits in the ssh-keysign-pwn repo within hours of the upstream disclosure.

The KernelCare rebootless patch is in build. Until it ships, you have one sysctl that stops the public PoC cold. Here’s what’s happening and what to do today.

How the Exploit Works

A 2017 refactor of __ptrace_may_access() (commit bfedb589, v4.10-rc1) silently inverted the access check when a task’s mm is NULL. The pre-refactor code denied access in that state. The refactored code falls through to allow.

During process exit, there is a microsecond-scale window where task->mm is already cleared, but the task’s file descriptors are still alive. The public PoC races a SUID process through that window using pidfd_open and pidfd_getfd, with two ready-made targets in the repo: chage to leak /etc/shadow, and ssh-keysign to leak SSH host private keys. The reported hit rate is 100 to 2,000 spawns per success.

Jann Horn proposed an equivalent fix in 2020 (v1, v2). It was not merged, and the bug stayed latent.

Who Is Affected

The regression was backported into the v4.4.40 stable series, so virtually every modern non-EL7 distribution kernel is in scope by default. Three groups:

Public PoC works out of the box:

• Debian 11, 12, 13
• Ubuntu 22.04, 24.04, 26.04
• Arch Linux (current)
• Raspberry Pi OS Bookworm
• CentOS Stream 9, AlmaLinux 9, RHEL 9, Oracle Linux 9, Rocky Linux 9
• AlmaLinux 10, RHEL 10

Vulnerable, but PoC needs adaptation:

• EL8 family (RHEL 8, AlmaLinux 8, Rocky 8, Oracle Linux 8)
• Ubuntu 20.04

Not affected:

• EL7 family on the 3.10 kernel – predates the 2017 regression

Mitigate Now

Tighten Yama ptrace_scope. The exploit reaches the bug via pidfd_getfd(). pidfd_getfd() calls ptrace_may_access(…, PTRACE_MODE_ATTACH_REALCREDS), which runs the LSM hook at the end of __ptrace_may_access. A Yama deny short-circuits the bug regardless of the buggy mm-NULL fall-through.

The common ptrace_scope=1 default (Debian / Ubuntu out-of-the-box) is NOT enough. Under scope=1, parent -> child attach is allowed. The attacker spawns the SUID process themselves, so they are the parent. You must move to scope=2 or scope=3.

Recommended: ptrace_scope=2 (admin-only attach, fully reversible at runtime):

sudo sysctl -w kernel.yama.ptrace_scope=2

Revert after the rebootless patch is installed:

sudo rm /etc/sysctl.d/99-ssh-keysign-pwn.conf

Stronger: ptrace_scope=3 (no attach for anyone, irreversible without reboot):

sudo sysctl -w kernel.yama.ptrace_scope=3

scope=3 is a one-way trip until reboot: the kernel rejects later attempts to lower it (sysctl -w kernel.yama.ptrace_scope=2 returns EINVAL). Choose this only if you can accept a reboot to revert and if root debug-attach (gdb -p, strace -p as root) is not part of your normal operations.

Compatibility

• scope=2 breaks unprivileged gdb -p / strace -p / perf trace --pid and container-debug flows root retains attach, so admin troubleshooting still works.
• scope=3 breaks debug-attach for everyone including root.

KernelCare Rebootless Patch

KernelCare has shipped rebootless patches for Ubuntu 22.04 (Jammy), Debian 11 (in ePortal), EL9 family (in test + main feeds), RHEL 8/Rocky Linux 8 (in test feed)

Once it’s released to the test feed:

kcarectl --update --prefix test

After validation, the patch arrives on the next scheduled run, or pull it on demand:

kcarectl --update

What to Watch for as this Develops

• CVE assignment: (none at time of writing)
• Qualys’s own advisory, which will likely carry a fuller technical writeup
• Distribution-kernel updates from Debian, Ubuntu, and the EL9/10 vendors
• New commits to the public ssh-keysign-pwn repo – the two current targets are unlikely to be the only viable ones

We’ll update this post when the CVE lands and when the KernelCare patch moves from test to stable. If you’re running KernelCare, the patch will deploy automatically, so no need to take any action.

If you are not yet a KernelCare user, now is a good time to see how rebootless patching can protect critical Linux systems without emergency maintenance windows or downtime.

Learn more about KernelCare here →