--- title: "Kernel-Lücke 'ssh-keysign-pwn' (CVE-2026-46333)" url: 'https://www.linuxfabrik.ch/de/blog/kernel-luecke-ssh-keysign-pwn' markdown: 'https://www.linuxfabrik.ch/de/blog/kernel-luecke-ssh-keysign-pwn.md' lang: de date: '2026-05-15' description: 'Linux-Kernel-Lücke ssh-keysign-pwn (CVE-2026-46333) im ptrace-Pfad betrifft RHEL und Derivate: Privilege Escalation. Wie man patcht und sich bis dahin schützt.' taxonomy: category: - blog tag: - linux - security archives_month: - may_2026 archives_year: - '2026' --- # Kernel-Lücke 'ssh-keysign-pwn' (CVE-2026-46333) [ Home ](https://www.linuxfabrik.ch/de) [ Blog ](https://www.linuxfabrik.ch/de/blog) Kernel-Lücke 'ssh-keysign-pwn' (CVE-2026-46333) Red Hat hat das Bulletin [RHSB-2026-004 "File Descriptor Theft via Process Exit Race Condition"](https://access.redhat.com/security/vulnerabilities/RHSB-2026-004) für eine Race Condition im Linux-Kernel veröffentlicht: CVE-2026-46333, im Umlauf als "ssh-keysign-pwn" oder "ptrace exit-race". Red Hat klassifiziert sie als *Important*, NVD listet CVSS 5.5. Betroffen sind RHEL 8, 9 und 10 sowie OpenShift Container Platform 4. Rocky Linux und AlmaLinux liefern bereits Patches aus, Red Hat zieht über das verlinkte Bulletin nach. Bis der reguläre Kernel-Patch eingespielt ist, gilt die offizielle Mitigation über den Yama-ptrace-Scope. **Update 2026-05-18:** Rocky Linux liefert den ssh-keysign-pwn-Kernel-Hot-Fix im opt-in [Security-Repository](https://www.linuxfabrik.ch/de/blog/rocky-linux-security-repo) aus: für Rocky 9 als `kernel-5.14.0-611.55.1.el9_7.0.3`, für Rocky 8 als `kernel-4.18.0-553.124.1.el8_10.0.2` (zusätzlich mit Backport `sched: fix exit_mm vs membarrier`), für Rocky 10 als `kernel-6.12.0-124.56.1.el10_1.0.3` (Patch `ptrace: slightly saner 'get_dumpable()' logic`). Aktivierungsschritte im verlinkten Artikel. ## Worum es geht Die Lücke sitzt in der Kernel-Funktion `__ptrace_may_access()` (in `kernel/ptrace.c`), dem internen Permission-Check für ptrace-Operationen, in dieser Form seit 2008 im Kernel. Beim Beenden eines Prozesses gibt der Kernel den Memory Descriptor (`mm_struct`) frei, bevor die Dateideskriptor-Tabelle geschlossen wird. In diesem schmalen Fenster überspringt die Permission-Prüfung den `dumpable`-Check, weil `mm` bereits `NULL` ist. Ein lokaler unprivilegierter Prozess kann das ausnutzen und über `pidfd_getfd(2)` (seit Linux 5.6) offene Datei-Deskriptoren aus einem privilegierten, gerade beendenden Prozess klauen. Angriffsziel sind SUID-Binaries, die im Normalbetrieb root-eigene Dateien öffnen und auf dem Exit-Pfad noch geöffnet halten. Konkret demonstriert wurden: - `ssh-keysign`: liest `/etc/ssh/ssh_host_*_key` (privater SSH-Host-Schlüssel) - `chage`: liest `/etc/shadow` (Passwort-Hashes) Demonstration und PoC im Writeup von `_SiCk`: [needhelp.icu/blogs/ssh-keysign-pwn](https://needhelp.icu/blogs/ssh-keysign-pwn/). Der gestohlene Deskriptor reicht aus, um die Datei in vollem Umfang zu lesen. Bei `ssh-keysign` heisst das, dass jeder lokale Account den privaten Host-Key abziehen und damit den Server-Identitäts-Trust kippen kann. Der oben skizzierte Code-Pfad ist der Pre-Fix-Zustand. Linus hat den Dumpable-Check inzwischen in `task_still_dumpable()` ausgelagert und mit einem `task->user_dumpable`-Fallback ergänzt; der Fix ist upstream merged, aber je nach Distribution noch nicht überall im Stable-Kernel angekommen. Eckdaten: - Red Hat-Public: 2026-05-16, Severity Important; NVD CVSS 5.5 Medium - Disclosure: Qualys an `security@kernel.org` - Upstream-Fix: 2026-05-14, Linus-Commit `31e62c2ebbfd` ("ptrace: slightly saner `get_dumpable()` logic") - Affected laut Red Hat: RHEL 8, 9 und 10 sowie OpenShift Container Platform 4 ## Bin ich betroffen? Jedes RHEL- und kompatible-System mit einem ungepatchten Kernel ist verwundbar, sobald lokale unprivilegierte Accounts auf der Maschine existieren. `pidfd_getfd(2)` ist ab Kernel 5.6 (RHEL 9) verfügbar; auf RHEL 8 ist der Logic-Bug ebenfalls vorhanden und wird gepatcht, der öffentliche PoC funktioniert dort aber weniger zuverlässig. Aktuellen Kernel und Yama-Status prüfen: ``` $ uname -r $ sysctl kernel.yama.ptrace_scope ``` Default auf der RHEL-Family ist `0` (uneingeschränktes ptrace). Werte `2` oder `3` deuten darauf hin, dass eine der unten beschriebenen Mitigationen bereits aktiv ist. ## Mitigation: Yama-ptrace-Scope hochziehen Yama ist ein LSM (Linux Security Module), also Teil des Kernel-Frameworks für ladbare Security-Policies wie SELinux oder AppArmor. Konfiguriert wird es über den sysctl `kernel.yama.ptrace_scope`. Red Hat empfiehlt eine der beiden Stufen. Wortlaut aus dem Bulletin: ``` $ echo "kernel.yama.ptrace_scope=2" | sudo tee /etc/sysctl.d/ptrace-restrict.conf $ sudo sysctl --system ``` Oder restriktiver: ``` $ echo "kernel.yama.ptrace_scope=3" | sudo tee /etc/sysctl.d/ptrace-restrict.conf $ sudo sysctl --system ``` Validierung: ``` $ sysctl kernel.yama.ptrace_scope ``` Was die Stufen bedeuten: - `2`: `ptrace_attach` nur mit `CAP_SYS_PTRACE`. Schliesst den `pidfd_getfd(2)`-Pfad für unprivilegierte Accounts, weil derselbe `__ptrace_may_access`-Check vorher greift. Debugger, die als Root oder mit gesetztem `CAP_SYS_PTRACE` laufen, funktionieren weiter. - `3`: ptrace komplett aus, auch für Root. Strikt und ohne Reboot nicht mehr rücksetzbar. Bricht `gdb`, `strace -p`, `perf` und alles, was auf ptrace aufsetzt. Für die meisten Production-Hosts ist Stufe `2` der vernünftige Kompromiss. ## Container-Hosts Yama ist ein LSM auf dem Host-Kernel, Container teilen den Kernel. Die Mitigation muss zwingend auf dem **Host** gesetzt werden, container-seitige seccomp-/SELinux-/AppArmor-Policies reichen nicht. Wer rootless Container betreibt, sollte Stufe `2` testen, bevor sie persistiert wird, weil typische Debug- und Tracing-Tools (`strace -p`, `gdb attach`, `perf` mit Attach) ohne `CAP_SYS_PTRACE` nachher nicht mehr funktionieren. ## Patch einspielen Rocky Linux liefert den Fix bereits über das opt-in [Security-Repository](https://www.linuxfabrik.ch/de/blog/rocky-linux-security-repo) aus. AlmaLinux hat die Patches am 2026-05-15 ins reguläre BaseOS gepusht: - 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` Update einspielen und neu starten: ``` $ sudo dnf check-update kernel $ sudo dnf upgrade kernel $ sudo systemctl reboot ``` Mitigation entfernen: ``` $ sudo rm /etc/sysctl.d/ptrace-restrict.conf $ sudo sysctl --system ``` Wer `ptrace_scope=3` gesetzt hatte, kommt nur über den Reboot wieder auf einen niedrigeren Wert. ## Wir helfen dir Brauchst du Unterstützung beim Patchen oder Härten deiner Linux-Server? Schau dir doch mal unsere [Service & Support-Modelle](https://www.linuxfabrik.ch/de/leistungen/service-support) an und melde dich [bei uns](https://www.linuxfabrik.ch/de/kontakt). [ Vorheriger Beitrag](https://www.linuxfabrik.ch/de/blog/rocky-linux-security-repo) [Nächster Beitrag ](https://www.linuxfabrik.ch/de/blog/mystic-iowait) #### Tags [ansible](https://www.linuxfabrik.ch/de/blog/tag:ansible) [checklistfabrik](https://www.linuxfabrik.ch/de/blog/tag:checklistfabrik) [cloud](https://www.linuxfabrik.ch/de/blog/tag:cloud) [datacenter](https://www.linuxfabrik.ch/de/blog/tag:datacenter) [event](https://www.linuxfabrik.ch/de/blog/tag:event) [firewallfabrik](https://www.linuxfabrik.ch/de/blog/tag:firewallfabrik) [graylog](https://www.linuxfabrik.ch/de/blog/tag:graylog) [icinga](https://www.linuxfabrik.ch/de/blog/tag:icinga) [lfops](https://www.linuxfabrik.ch/de/blog/tag:lfops) [linux](https://www.linuxfabrik.ch/de/blog/tag:linux) [monitoring-plugins](https://www.linuxfabrik.ch/de/blog/tag:monitoring-plugins) [news](https://www.linuxfabrik.ch/de/blog/tag:news) [nextcloud](https://www.linuxfabrik.ch/de/blog/tag:nextcloud) [security](https://www.linuxfabrik.ch/de/blog/tag:security) #### Archiv - [2026](https://www.linuxfabrik.ch/de/blog/archives_year:2026) - [2025](https://www.linuxfabrik.ch/de/blog/archives_year:2025) - [2024](https://www.linuxfabrik.ch/de/blog/archives_year:2024) - [2023](https://www.linuxfabrik.ch/de/blog/archives_year:2023) - [2022](https://www.linuxfabrik.ch/de/blog/archives_year:2022) - [2021](https://www.linuxfabrik.ch/de/blog/archives_year:2021) - [2020](https://www.linuxfabrik.ch/de/blog/archives_year:2020) #### Abonnements [ Atom](https://www.linuxfabrik.ch/de/blog.atom) [ RSS](https://www.linuxfabrik.ch/de/blog.rss) --- ## Navigation - Parent: [Blog](https://www.linuxfabrik.ch/de/blog.md) - Previous: [Warum wir iowait nicht mehr messen](https://www.linuxfabrik.ch/de/blog/mystic-iowait.md) - Next: [Rocky Linux Security-Repository](https://www.linuxfabrik.ch/de/blog/rocky-linux-security-repo.md)