Kernel-Lücke 'ssh-keysign-pwn' (CVE-2026-46333)

linux security

Red Hat hat das Bulletin RHSB-2026-004 "File Descriptor Theft via Process Exit Race Condition" 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 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.

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 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 an und melde dich bei uns.

Vorheriger Beitrag

DE · EN