--- title: "Kernel Vulnerability 'ssh-keysign-pwn' (CVE-2026-46333)" url: 'https://www.linuxfabrik.ch/en/blog/kernel-vulnerability-ssh-keysign-pwn' markdown: 'https://www.linuxfabrik.ch/en/blog/kernel-vulnerability-ssh-keysign-pwn.md' lang: en date: '2026-05-15' description: 'Linux kernel vulnerability ssh-keysign-pwn (CVE-2026-46333) in the ptrace path affects RHEL and derivatives: privilege escalation. How to patch and how to protect yourself until then.' taxonomy: category: - blog tag: - linux - security archives_month: - may_2026 archives_year: - '2026' --- # Kernel Vulnerability 'ssh-keysign-pwn' (CVE-2026-46333) [ Home ](https://www.linuxfabrik.ch/en) [ Blog ](https://www.linuxfabrik.ch/en/blog) Kernel Vulnerability 'ssh-keysign-pwn' (CVE-2026-46333) Red Hat published bulletin [RHSB-2026-004 "File Descriptor Theft via Process Exit Race Condition"](https://access.redhat.com/security/vulnerabilities/RHSB-2026-004) 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](https://www.linuxfabrik.ch/en/blog/rocky-linux-security-repo): 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](https://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](https://www.linuxfabrik.ch/en/blog/rocky-linux-security-repo). 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](https://www.linuxfabrik.ch/en/services/service-support) and [get in touch](https://www.linuxfabrik.ch/en/contact). [ Previous Post](https://www.linuxfabrik.ch/en/blog/rocky-linux-security-repo) [Next Post ](https://www.linuxfabrik.ch/en/blog/mystic-iowait) #### Tags [ansible](https://www.linuxfabrik.ch/en/blog/tag:ansible) [checklistfabrik](https://www.linuxfabrik.ch/en/blog/tag:checklistfabrik) [cloud](https://www.linuxfabrik.ch/en/blog/tag:cloud) [datacenter](https://www.linuxfabrik.ch/en/blog/tag:datacenter) [event](https://www.linuxfabrik.ch/en/blog/tag:event) [firewallfabrik](https://www.linuxfabrik.ch/en/blog/tag:firewallfabrik) [graylog](https://www.linuxfabrik.ch/en/blog/tag:graylog) [icinga](https://www.linuxfabrik.ch/en/blog/tag:icinga) [lfops](https://www.linuxfabrik.ch/en/blog/tag:lfops) [linux](https://www.linuxfabrik.ch/en/blog/tag:linux) [monitoring-plugins](https://www.linuxfabrik.ch/en/blog/tag:monitoring-plugins) [news](https://www.linuxfabrik.ch/en/blog/tag:news) [nextcloud](https://www.linuxfabrik.ch/en/blog/tag:nextcloud) [security](https://www.linuxfabrik.ch/en/blog/tag:security) #### Archives - [2026](https://www.linuxfabrik.ch/en/blog/archives_year:2026) - [2025](https://www.linuxfabrik.ch/en/blog/archives_year:2025) - [2024](https://www.linuxfabrik.ch/en/blog/archives_year:2024) - [2023](https://www.linuxfabrik.ch/en/blog/archives_year:2023) - [2022](https://www.linuxfabrik.ch/en/blog/archives_year:2022) - [2021](https://www.linuxfabrik.ch/en/blog/archives_year:2021) - [2020](https://www.linuxfabrik.ch/en/blog/archives_year:2020) #### Syndicate [ Atom](https://www.linuxfabrik.ch/en/blog.atom) [ RSS](https://www.linuxfabrik.ch/en/blog.rss) --- ## Navigation - Parent: [Blog](https://www.linuxfabrik.ch/en/blog.md) - Previous: [Why we stopped measuring iowait](https://www.linuxfabrik.ch/en/blog/mystic-iowait.md) - Next: [Rocky Linux Security Repository](https://www.linuxfabrik.ch/en/blog/rocky-linux-security-repo.md)