Neue Kernel-Sicherheitslücke CVE-2026-43494 „PinTheft“ ermöglicht lokale Root-Rechte, wenn RDS und io_uring ungeschützt sind

Die Kurzfassung

Was: Eine neue Schwachstelle zur lokalen Privilegienausweitung unter Linux namens „PinTheft“. Sie nutzt einen Refcount-Fehler im Zerocopy-Sendepfad des RDS-Moduls (Reliable Datagram Sockets) des Kernels in Verbindung mit „io_uring“, um eine SUID-Root-Binärdatei im Speicher zu überschreiben. Das Ergebnis ist eine Root-Shell von einem nicht privilegierten lokalen Konto aus. Zum Zeitpunkt der Veröffentlichung wurde noch keine CVE-Nummer vergeben.

Auswirkungen: Ein öffentlicher Proof-of-Concept von V12 Security ermöglicht es jedem lokalen Benutzer ohne Sonderrechte, auf betroffenen Hosts zuverlässig Root-Rechte zu erlangen. Der zugrunde liegende Fehler ist seit Version 4.17 des Linux-Kernels, die 2018 veröffentlicht wurde, vorhanden.

Status: Aaron Esau von V12 Security, dem Unternehmen, dem die Entdeckung zugeschrieben wird, hat PinTheft im Mai bekannt und stellte bereits einen Kernel-Patch zur Verfügung. Der Kandidat für den Upstream-Fix wurde am 5. Mai 2026 auf der netdev-Kernel-Mailingliste veröffentlicht. Es wurde die CVE-2026-43494 zugewiesen, ohne CVSS-Score. Den aktuellen Status finden Sie im Abschnitt „KernelCare Rebootless Patch“ weiter unten.

Schweregrad: Lokaler Vektor; erfordert die Möglichkeit, Code auf dem Host als beliebiger lokaler Benutzer auszuführen; keine Benutzerinteraktion erforderlich. Für eine praktische Ausnutzung müssen auf dem Zielsystem alle folgenden Voraussetzungen erfüllt sein: RDS und RDS_TCP müssen verfügbar und ladbar sein, io_uring muss aktiviert sein, es muss eine lesbare SUID-Root-Binärdatei vorhanden sein und es muss eine x86_64-Payload vorhanden sein (der PoC ist architekturabhängig, auch wenn die Technik selbst dies nicht ist). V12 gab an, dass unter den gängigen Distributionen, die sie getestet haben, RDS standardmäßig nur unter Arch Linux ladbar war. Andere Distributionen liefern das Modul so aus, dass es nicht automatisch geladen wird, oder bauen es gar nicht erst ein.

Warum dies wichtig ist: Die Exploit-Kette ist zuverlässig, der Proof-of-Concept ist öffentlich zugänglich, und es gibt bislang weder eine CVE-Kennung noch eine offizielle Sicherheitswarnung des Herstellers. Multi-Tenant-Linux-Systeme (Shared Hosting, CI-Runner, Container-Hosts) auf den betroffenen Distributionen sollten als unmittelbar gefährdet betrachtet werden.

Gehen Sie wie folgt vor: Falls Ihr Host keine RDS-Workloads ausführt – was bei den meisten der Fall ist –, blockieren Sie die Module „rds“ und „rds_tcp“ mithilfe einer „modprobe“-Regel. Wenn „io_uring“ nicht benötigt wird und Ihr Kernel die Version 6.6 oder höher hat, können Sie es zusätzlich mit einem einzigen „sysctl“-Befehl deaktivieren. Die Befehle zur Abhilfe sowie die Ausweichlösung für ältere Kernel finden Sie weiter unten.

Die Langfassung

V12 Security veröffentlichte im Mai 2026 den „PinTheft“-Proof-of-Concept sowie einen technischen Bericht. Die Entdeckung wird Aaron Esau zugeschrieben. Die Schwachstelle selbst ist bereits seit Version 4.17 des Linux-Kernels aus dem Jahr 2018 vorhanden, doch die Exploit-Kette hängt von io_uring-Funktionen ab, die zum Zeitpunkt der Einführung des Fehlers noch nicht existierten.

Der vorläufige Kernel-Fix wurde am 5. Mai 2026 an die netdev-Mailingliste gesendet. Die Kernel der nachgelagerten Distributionen übernehmen ihn derzeit noch. Die Entwickler von KernelCare bereiten Patches vor, die einen Neustart überflüssig machen, für die betroffenen unterstützten Kernel.

In einigen frühen Berichten wurde PinTheft ausdrücklich mit dem Kernel 6.13 und späteren Versionen in Verbindung gebracht. Dies spiegelt die Abhängigkeiten des veröffentlichten PoC wider, nicht jedoch die Dauer des zugrunde liegenden Fehlers – das Problem mit der Referenzzählung im RDS-Zerocopy-Pfad ist zwar schon viel älter, doch eine funktionierende Exploit-Kette, die dem PoC nachempfunden ist, erfordert nach wie vor neuere io_uring-Funktionen.

So funktioniert der Exploit

Wenn ein Programm Daten über einen Netzwerk-Socket sendet, kopiert der Kernel diese Daten normalerweise aus dem Speicher des Programms in Kernel-Puffer. Um CPU-Zyklen zu sparen, bieten moderne Kernel auch das „Zerocopy“-Senden an: Der Kernel sperrt die Speicherseiten des Benutzers und nutzt sie direkt. RDS, ein weniger verbreitetes Protokoll für Hochleistungsnetzwerke in Rechenzentren, unterstützt diesen Zerocopy-Modus.

Der Fehler liegt darin, wie RDS nach einem fehlgeschlagenen Zerocopy-Versand aufräumt. Der Kernel gibt die gleichen Seiten am Ende zweimal statt nur einmal frei. Jeder fehlgeschlagene Versand entzieht der ersten Benutzerseite eine Referenz.

Für sich genommen ist das nur ein kleiner Buchhaltungsfehler. PinTheft macht daraus über io_uring, die moderne asynchrone E/A-Schnittstelle von Linux, einen Root-Exploit. io_uring ermöglicht es einem Programm, eine Speicherseite als festen Puffer zu registrieren, wodurch 1.024 Verweise auf diese Seite hinzugefügt werden. Der Angreifer erzwingt dann 1.024 fehlgeschlagene RDS-Zerocopy-Übertragungen, um all diese Verweise unbemerkt aufzubrauchen. Der Kernel geht nun davon aus, dass niemand die Seite nutzt, und gibt sie frei, doch io_uring hält weiterhin einen Zeiger darauf.

Anschließend liest der Angreifer eine beliebige SUID-Root-Binärdatei ein. Der Kernel lädt diese Binärdatei in dieselbe freigegebene Seite seines Seiten-Caches. Ein einziger io_uring-Schreibvorgang in den veralteten Puffer überschreibt die Binärdatei im Speicher mit Shellcode. Durch das Ausführen der SUID-Binärdatei gelangt der Benutzer nun in eine Root-Shell.

Die Datei auf der Festplatte bleibt unverändert. Es wird lediglich die Kopie im Seiten-Cache im Arbeitsspeicher überschrieben. Dies ist für die Bereinigung von Bedeutung, worauf im Abschnitt zu den Abhilfemaßnahmen eingegangen wird.

Der Fehler im Zusammenhang mit dem latenten Referenzzähler scheint auf die Einführung der RDS-Zerocopy-Unterstützung in Linux 4.x zurückzugehen. Eine zuverlässige Ausnutzung, wie sie im PoC gezeigt wird, hängt zudem von neueren io_uring-Funktionen ab (insbesondere IORING_REGISTER_CLONE_BUFFERS, verfügbar ab Version 6.12); obwohl der Fehler also schon lange bekannt ist, ist das Zeitfenster für eine praktische Ausnutzung geringer.

Wer ist betroffen?

Entscheidend ist allein, ob der laufende Kernel die RDS-Module laden kann, nicht der Name der Distribution. Überprüfen Sie die Kernelkonfiguration und die Richtlinien zum Laden von Modulen direkt mit den Befehlen im nächsten Abschnitt.

Standardmäßig bootfähiges RDS (von den Forschern bestätigt): Arch Linux.

Das RDS-Modul ist enthalten, wird jedoch standardmäßig am automatischen Laden gehindert: Ubuntu (alle derzeit unterstützten Versionen, über eine Blacklist-Datei im kmod-Paket), Debian 11 und 12 (über einen Debian-spezifischen Patch, der das automatische Laden von RDS als Schutzmaßnahme gegen lokale Exploits deaktiviert), Fedora (CONFIG_RDS=m, das Modul ist jedoch in kernel-modules-extra enthalten und verfügt über eine eigene Blacklist-Datei). Auf diesen Systemen erfordert der PoC, dass ein Administrator oder eine Workload rds_tcp absichtlich zuerst lädt. Unabhängige Tests berichten zudem, dass das Laden des Moduls auf einem serienmäßigen Debian-basierten System nicht immer ausreicht, damit der PoC erfolgreich ist, sodass das Verhalten variiert.

Erfordert eine hersteller- oder konfigurationsspezifische Überprüfung: Amazon Linux 2023, openSUSE Tumbleweed, Proxmox VE 7/8/9, Oracle Linux UEK 6 und 7. Überprüfen Sie die Datei „CONFIG_RDS“ im Verzeichnis „/boot/config-$(uname -r)“ und suchen Sie nach vom Hersteller bereitgestellten „modprobe“-Regeln in den Verzeichnissen „/etc/modprobe.d/“ und „/lib/modprobe.d/“.

Nicht betroffen: RHEL, AlmaLinux, Rocky Linux und CentOS Stream 8/9/10, auf denen der standardmäßige Red Hat-kompatible Kernel läuft – diese Versionen enthalten kein RDS. Bei RHEL 9 und 10 ist io_uring zudem standardmäßig deaktiviert, wodurch die andere Hälfte der Kette entfällt.

Eine Einschränkung, die alle oben genannten Punkte außer Kraft setzt: Jeder Host, auf dem ein benutzerdefinierter oder alternativer Kernel läuft, kann sich anders verhalten als die zugehörige Distribution. Insbesondere Oracle Linux UEK läuft oft parallel zum RHCK und befindet sich in einem anderen Zustand.

Jetzt Maßnahmen ergreifen

Es gibt zwei praktische Abhilfemaßnahmen. Entscheiden Sie sich je nachdem, ob Ihr Host tatsächlich RDS oder io_uring verwendet.

Empfehlung für die meisten Hosts: Blockieren Sie die RDS-Module

Die überwiegende Mehrheit der Linux-Server nutzt RDS nicht. Es kommt hauptsächlich in Oracle-Clusterware und einigen HPC-InfiniBand-Konfigurationen zum Einsatz. Auf jedem Host, auf dem keine RDS-Workloads ausgeführt werden, besteht die einfachste Lösung darin, das Laden der Module „rds“ und „rds_tcp“ zu unterbinden.

sudo sh -c "printf 'install rds /bin/false\ninstall rds_tcp /bin/false\n' > /etc/modprobe.d/pintheft.conf"
sudo rmmod rds_tcp rds 2>/dev/null || true

Der Exploit überschreibt die SUID-Binärdatei ausschließlich im Arbeitsspeicher. Die Datei auf der Festplatte bleibt unverändert. Löschen Sie auf jedem Host, der vor der Behebung der Sicherheitslücke möglicherweise angegriffen wurde, den Seiten-Cache, um alle Änderungen im Arbeitsspeicher zu entfernen:

sudo sh -c 'echo 3 > /proc/sys/vm/drop_caches'

Zurücksetzen nach dem Anwenden des Kernel-Patches oder des KernelCare-Live-Patches:

sudo rm /etc/modprobe.d/pintheft.conf

Wenn Sie RDS-Workloads ( Oracle Clusterware, bestimmte HPC-Stacks) ausführen , wenden Sie diese Abhilfemaßnahme nicht an. Verwenden Sie stattdessen die unten beschriebene io_uring-Alternative oder warten Sie auf den gepatchten Kernel.

Alternative: io_uring systemweit deaktivieren

Der Sysctl-Parameter `kernel.io_uring_disabled` ist unter Linux 6.6 und neuer verfügbar. Ältere Distributionen – darunter Ubuntu 22.04 (5.15), Debian 11 (5.10) und 12 (6.1), Amazon Linux 2023 (6.1), RHEL 9 (5.14) und Ubuntu 24.04 (6.8 – überprüfen Sie Ihre Point-Release) – stellen diesen Sysctl nicht zur Verfügung.

Auf diesen Kerneln ist das Sperren der RDS-Module die praktikablere Option. Das vollständige Deaktivieren von io_uring auf älteren Kerneln erfordert einen Boot-Parameter oder eine Neuerstellung des Kernels und ist im Vergleich zum Sperren von RDS in der Regel den Aufwand nicht wert.

Falls io_uring für Ihre Workloads nicht erforderlich ist, deaktivieren Sie stattdessen die andere Hälfte der Exploit-Kette.

sudo sysctl -w kernel.io_uring_disabled=2

Dies ist die Standardeinstellung unter RHEL 10 und der Grund dafür, dass diese Distributionsfamilie unabhängig vom RDS-Status außerhalb des Anwendungsbereichs bleibt. Beachten Sie, dass die Deaktivierung von io_uring Auswirkungen auf einige moderne Datenbank-Engines und asynchrone E/A-Workloads haben kann. Testen Sie dies in Ihrer Umgebung, bevor Sie die Änderung übernehmen.

Auch nach einem Neustart beibehalten:

echo 'kernel.io_uring_disabled = 2' | sudo tee /etc/sysctl.d/99-pintheft.conf
sudo sysctl --system

Mehrschichtige Verteidigung auf gehärteten Hosts

Wenn Ihre Workload Kernel-Module nicht zur Laufzeit lädt, verhindert die Einstellung „kernel.modules_disabled=1“ nach dem Systemstart, dass weitere „modprobe“-Aufrufe erfolgreich ausgeführt werden, wodurch der Autoload-Pfad für RDS und alle anderen Module auf einmal geschlossen wird.

Dies ist aggressiver als die gezielte Sperrung von RDS und sollte nur dort eingesetzt werden, wo kein Laden von Laufzeitmodulen zu erwarten ist (keine Hot-Plug-Hardware, keine On-Demand-Dateisystem- oder Netzwerkmodule, keine Container-Laufzeitumgebungen, die Module bei der ersten Verwendung laden).

sudo sysctl -w kernel.modules_disabled=1

Beachten Sie, dass diese Einstellung innerhalb eines Bootvorgangs nur in eine Richtung geändert werden kann – sie kann ohne Neustart nicht wieder auf 0 zurückgesetzt werden. Testen Sie die Einstellung vor der Einführung in einer Nicht-Produktionsumgebung.

Überprüfen Sie, ob Ihr Host angreifbar ist

Führen Sie die drei folgenden Überprüfungen durch und vergleichen Sie die Ergebnisse mit den Kriterien am Ende dieses Abschnitts.

1. Ist RDS in der Kernel-Version enthalten?

   grep -E 'CONFIG_(RDS|RDS_TCP|IO_URING)' /boot/config-$(uname -r)
   modprobe -n -v rds_tcp
   ls /lib/modules/$(uname -r)/kernel/net/rds/ 2>/dev/null

2. Ist io_uring aktiviert?

   cat /proc/sys/kernel/io_uring_disabled

3. Sind die Module bereits auf der Sperrliste?

   grep -rEn '^\s*(blacklist|install)\s+rds' /etc/modprobe.d/ /etc/modules-load.d/ 2>/dev/null

Ein Host ist nur dann ein geeignetes Ziel, wenn alle folgenden Bedingungen erfüllt sind: CONFIG_RDS und CONFIG_RDS_TCP sind verfügbar, io_uring_disabled ist auf 0 gesetzt und die Module rds und rds_tcp stehen nicht auf der Sperrliste.

KernelCare Rebootless Patch

Dieser Abschnitt wird aktualisiert, sobald neue Patches veröffentlicht werden. Achten Sie auf den Zeitstempel in der Aktualisierungszeile am Anfang des Beitrags.

Stand: 21.05.2026, 12:00 Uhr UTC: KernelCare-Patches für alle Distributionen (mit Ausnahme von Debian 12 und Proxmox 8) wurden in den Haupt-Feed übernommen.

Sobald im Test-Feed verfügbar:

kcarectl --update --prefix test

Nach der Validierung wird der Patch beim nächsten geplanten Durchlauf bereitgestellt, oder Sie können ihn bei Bedarf abrufen:

kcarectl --update

Überprüfen Sie, ob der Patch installiert wurde. Sobald eine CVE-Nummer zugewiesen wurde, überprüfen Sie dies mit:

kcarectl --patch-info | grep CVE-XXXX-XXXXX   # durch die CVE-Nummer ersetzen

Was man im weiteren Verlauf im Auge behalten sollte

• CVE-Zuweisung (zum Zeitpunkt der Erstellung dieses Artikels keine)
• Eine offizielle Mitteilung von V12 Security oder dem Kernel-Sicherheitsteam
• Verteilung von Kernel-Updates von Ubuntu, Debian, Amazon Linux, openSUSE, Oracle und Proxmox
• Veröffentlichung des KernelCare-Patches für alle unterstützten Kernel-Versionen

Dieser Beitrag wird aktualisiert, sobald die CVE-Nummer vergeben wurde und die KernelCare-Patches vom Teststatus in den stabilen Status übergehen. KernelCare-Kunden erhalten den Patch automatisch, sobald er in den Haupt-Feed übernommen wurde.

Jeden Kernel patchen, kein Neustart erforderlich

Wenn Sie noch kein KernelCare-Nutzer sind, ist jetzt ein guter Zeitpunkt, um zu erfahren, wie Patches ohne Neustart kritische Linux-Systeme schützen können, ohne dass Notfallwartungsfenster oder Ausfallzeiten erforderlich sind.

Erfahren Sie hier mehr über KernelCare →