Kernel Vulnerability 'ssh-keysign-pwn' (CVE-2026-46333)

linux security

Red Hat published bulletin RHSB-2026-004 "File Descriptor Theft via Process Exit Race Condition" for a race condition in the Linux kernel: CVE-2026-46333, going around as "ssh-keysign-pwn" or "ptrace exit-race". Red Hat rates it Important, NVD lists CVSS 5.5. Affected are RHEL 8, 9 and 10 and OpenShift Container Platform 4. Rocky Linux and AlmaLinux already ship fixes, Red Hat tracks the rollout in the linked bulletin. Until the regular kernel patch is in, the official mitigation through the Yama ptrace scope applies.

Update 2026-05-18: Rocky Linux ships the ssh-keysign-pwn kernel hot-fix through the opt-in security repository: for Rocky 9 as kernel-5.14.0-611.55.1.el9_7.0.3, for Rocky 8 as kernel-4.18.0-553.124.1.el8_10.0.2 (with the additional backport sched: fix exit_mm vs membarrier), for Rocky 10 as kernel-6.12.0-124.56.1.el10_1.0.3 (patch ptrace: slightly saner 'get_dumpable()' logic). Activation steps in the linked article.

What it is

The flaw sits in the kernel function __ptrace_may_access() (in kernel/ptrace.c), the internal permission check for ptrace operations, present in this form in the kernel since 2008. When a process exits, the kernel releases the memory descriptor (mm_struct) before closing the file descriptor table. In that narrow window the permission check skips its dumpable safeguard because mm is already NULL. A local unprivileged process can exploit this and use pidfd_getfd(2) (since Linux 5.6) to steal open file descriptors from a privileged, currently exiting process.

The attack targets SUID binaries that open root-owned files during normal operation and still hold them on the exit path. Concretely demonstrated:

  • ssh-keysign: reads /etc/ssh/ssh_host_*_key (the private SSH host key)
  • chage: reads /etc/shadow (password hashes)

Demonstration and PoC in the writeup by _SiCk: needhelp.icu/blogs/ssh-keysign-pwn.

The stolen descriptor is enough to read the file in full. For ssh-keysign that means any local account can extract the private host key and break the server identity trust.

The code path described above is the pre-fix state. Linus has since moved the dumpable check into task_still_dumpable() and added a task->user_dumpable fallback; the fix is upstream-merged but not yet shipped in every distribution's stable kernel.

Key facts:

  • Red Hat public date: 2026-05-16, severity Important; NVD CVSS 5.5 Medium
  • Disclosure: Qualys to security@kernel.org
  • Upstream fix: 2026-05-14, Linus commit 31e62c2ebbfd ("ptrace: slightly saner get_dumpable() logic")
  • Affected per Red Hat: RHEL 8, 9 and 10 and OpenShift Container Platform 4

Am I affected?

Every RHEL and compatible system with an unpatched kernel is vulnerable as soon as local unprivileged accounts exist on the machine. pidfd_getfd(2) is available from kernel 5.6 (RHEL 9); on RHEL 8 the logic bug is present and is being patched too, but the public PoC works less reliably there.

Check the current kernel and Yama status:

$ uname -r
$ sysctl kernel.yama.ptrace_scope

Default on the RHEL family is 0 (unrestricted ptrace). A value of 2 or 3 indicates that one of the mitigations described below is already active.

Mitigation: raise the Yama ptrace scope

Yama is an LSM (Linux Security Module), part of the kernel framework for loadable security policies like SELinux or AppArmor. It is configured via the kernel.yama.ptrace_scope sysctl. Red Hat recommends one of the two levels. From the bulletin:

$ echo "kernel.yama.ptrace_scope=2" | sudo tee /etc/sysctl.d/ptrace-restrict.conf
$ sudo sysctl --system

Or more restrictively:

$ echo "kernel.yama.ptrace_scope=3" | sudo tee /etc/sysctl.d/ptrace-restrict.conf
$ sudo sysctl --system

Validation:

$ sysctl kernel.yama.ptrace_scope

What the levels mean:

  • 2: ptrace_attach only with CAP_SYS_PTRACE. Closes the pidfd_getfd(2) path for unprivileged accounts, since the same __ptrace_may_access check is hit first. Debuggers running as root or with CAP_SYS_PTRACE keep working.
  • 3: ptrace fully off, including for root. Strict and cannot be reverted without a reboot. Breaks gdb, strace -p, perf and anything that builds on ptrace.

For most production hosts level 2 is the sensible compromise.

Container hosts

Yama is an LSM on the host kernel, containers share the kernel. The mitigation has to go on the host, container-side seccomp/SELinux/AppArmor policies are not enough. If you run rootless containers, test level 2 before persisting it, since typical debug and tracing tools (strace -p, gdb attach, perf with attach) will then no longer work without CAP_SYS_PTRACE.

Apply the patch

Rocky Linux already ships the fix through the opt-in security repository. AlmaLinux pushed the patches into regular BaseOS on 2026-05-15:

  • AlmaLinux 8: kernel-4.18.0-553.124.4.el8_10
  • AlmaLinux 9: kernel-5.14.0-611.54.6.el9_7
  • AlmaLinux 10: kernel-6.12.0-124.56.5.el10_1

Apply the update and reboot:

$ sudo dnf check-update kernel
$ sudo dnf upgrade kernel
$ sudo systemctl reboot

Remove the mitigation:

$ sudo rm /etc/sysctl.d/ptrace-restrict.conf
$ sudo sysctl --system

If you used ptrace_scope=3, only a reboot gets you back to a lower value.

We can help

Need help patching or hardening your Linux servers? Have a look at our Service & Support plans and get in touch.

Previous Post

DE · EN