Wie VsockDrop ohne Hypervisor und ohne Sonderrechte Root-Rechte erlangt

Die Kurzfassung

Zur Langfassung springen ↓

Für eine Linux-Kernel-Sicherheitslücke mit einer Schweregradbewertung von 5,5 gibt es nun einen öffentlich zugänglichen Exploit, der es einem lokalen Benutzer ohne Sonderrechte ermöglicht, Root-Rechte zu erlangen. Das ist der Aspekt von „VsockDrop“ (CVE-2026-53365), der diese Woche Maßnahmen erfordert.

Was es ist: VsockDrop ist ein Exploit zur lokalen Privilegienausweitung (LPE) für CVE-2026-53365, einen Fehler im „virtio vsock zerocopy“-Sendepfad des Linux-Kernels. Wenn ein großes MSG_ZEROCOPY-Fragment über mehrere Socket-Puffer gesendet wird, enthält nur der letzte Puffer das Abschlussobjekt, nach dem der Freigabepfad sucht. Jeder davor liegende Puffer enthält festgehaltene Benutzerseiten, und der Kernel verwirft daraufhin eine Seitenreferenz, die er nie aufgenommen hat.

Mögliche Auswirkungen: Erlangung von Root-Rechten aus einem gewöhnlichen, nicht privilegierten Konto. Der Exploit reduziert den Seitenreferenzzähler auf Null, lässt sich die noch fixierte Seite als Seitencache für /usr/bin/su zurückgeben, schreibt den darin gespeicherten Interpreter-Pfad um und führt su aus. In der gesamten Kette gibt es weder einen Informationsleck noch eine Ausführung von Kernel-Code, was zu einem großen Teil der Grund dafür ist, dass der Exploit so konsistent funktioniert.

Schweregrad: Sowohl Red Hat als auch das NVD geben für CVE-2026-53365 einen CVSS-Basiswert von 5,5 an, mit erheblichen Auswirkungen auf die Verfügbarkeit, jedoch ohne Auswirkungen auf die Vertraulichkeit oder Integrität; Red Hat stuft die Schwere als „mäßig“ ein. Der Autor des Exploits plädiert für einen Wert von 7,8. Der Vektor beschreibt den Fehler bei der Ressourcenabrechnung, der in der Upstream-Commit-Meldung dokumentiert ist. Er berücksichtigt jedoch nicht die io_uring-Interaktion, durch die dasselbe fehlende Abschlussobjekt in eine freigegebene Seite umgewandelt wird, während es noch in Gebrauch ist. Unabhängig vom endgültigen Bewertungsergebnis zeigt der öffentlich zugängliche Exploit Auswirkungen auf Vertraulichkeit und Integrität auf, die der derzeit veröffentlichte Vektor von 5,5 nicht erfasst.

Wer ist betroffen: Ubuntu verdient die dringendste Aufmerksamkeit. Betroffen sind Linux-Kernel ab Version 6.7, bei denen der Fix noch nicht installiert wurde. Die Ausnutzbarkeit hängt davon ab, dass ein Prozess ohne Sonderrechte in der Lage ist, bei io_uring registrierte Puffer in Verbindung mit einem vsock-Transport zu nutzen, der Zerocopy zulässt. Beides ist standardmäßig unter Ubuntu 24.04 sowie unter Ubuntu 22.04 mit dem 6.8-HWE-Kernel verfügbar. Enterprise Linux 9 und 10, darunter RHEL, AlmaLinux, Rocky und CloudLinux, enthalten denselben anfälligen Code, werden jedoch mit dem Wert 2 für „kernel.io_uring_disabled“ ausgeliefert, wodurch die demonstrierte Angriffskette blockiert wird.

Was wurde überprüft: Am 18. August 2026 gelang es TuxCare, auf Ubuntu 24.04 bereits beim ersten Versuch und ohne Konfigurationsänderungen eine Root-Shell von einem Konto ohne Sonderrechte aus zu reproduzieren. Unter AlmaLinux 10.2 brach derselbe Exploit bei der Initialisierung von io_uring in der Standardkonfiguration ab, führte jedoch zu Root-Rechten, sobald io_uring explizit wieder aktiviert wurde. Ein Versuch unter AlmaLinux 9.8 mit wieder aktiviertem io_uring führte nicht zu Root-Rechten, was jedoch nicht mit einem eindeutigen Negativbefund gleichzusetzen ist.

Was nun zu tun ist: Ermitteln Sie den laufenden Kernel und die io_uring-Richtlinie und prüfen Sie anschließend, ob vsock geladen ist.

uname -r
sysctl kernel.io_uring_disabled
lsmod | grep -E 'vsock|vmw_vsock'

Der Wert 2 bedeutet, dass „io_uring“ systemweit, auch für Root, deaktiviert ist, wodurch der bekannte Root-Exploit-Pfad blockiert wird, ohne den anfälligen Code zu entfernen. Der Wert 0 bedeutet, dass „io_uring“ verfügbar ist; dies ist die Standard-Einstellung des Upstreams und entspricht der Auslieferung durch Ubuntu. Die Ausgabe des dritten Befehls bestätigt, dass ein vsock-bezogenes Modul geladen ist. Der öffentlich bekannte Exploit kann „vsock_loopback“ und „VMADDR_CID_LOCAL“ nutzen, sodass keine virtuelle Maschine erforderlich ist.

Verwenden Sie einen festen Hersteller-Kernel, sofern vorhanden. Debian 13 verfügt über einen solchen. Canonical hat für die beiden wichtigsten Ubuntu-Reihen noch keinen bereitgestellt. Wenn ein Neustart nicht sofort möglich ist, ist KernelCare der übliche Weg zu einem lauffähigen Kernel, der den Fehler nicht mehr enthält. Da für diese CVE noch kein Patch ohne Neustart veröffentlicht wurde, stellen die unten aufgeführten Abhilfemaßnahmen vorerst die einzige Lösung für diese Systeme dar.

Das Interessante an VsockDrop ist nicht, dass es eine weitere CVE für den Linux-Kernel gibt. Es ist vielmehr die Diskrepanz zwischen dem, was im CVE-Eintrag beschrieben wird, und dem, was der öffentlich zugängliche Exploit tatsächlich bewirkt.

CVE-2026-53365 wurde am 13. Juli 2026 veröffentlicht, zwei Monate nachdem die Korrektur bereits am 14. Mai im Upstream-Projekt implementiert worden war. Die offizielle Beschreibung befasst sich mit der Nachverfolgung des Abschlusses von Zerocopy-Vorgängen und mit festgelegten Seiten, die niemals freigegeben werden. Sowohl Red Hat als auch das NVD bewerten dies mit einer Schwere von 5,5 und Auswirkungen, die sich ausschließlich auf die Verfügbarkeit beschränken.

Dann veränderte der öffentlich bekannt gewordene Exploit die praktische Situation. Er zeigte, dass derselbe Fehler in der Referenzverwaltung in Verbindung mit überlaufenden registrierten Puffern dazu führt, dass eine Seite freigegeben wird, die noch „gepinnt“ ist, im Rahmen einer setuid-Binärdatei wiederverwendet wird und einen gewöhnlichen lokalen Benutzer zu „root“ macht.

Ein Fehler, zwei Folgen. Die CVE hat die weniger schwerwiegende erfasst. Wenn eine Bewertung von 5,5 in einem Schwachstellenbericht der Grund dafür ist, dass dieser Eintrag aus der Patch-Liste gestrichen wurde, gehört er wieder hinein.

Was hat es mit CVE-2026-53365, auch bekannt als „VsockDrop“, auf sich?

VsockDrop ist ein Exploit zur lokalen Privilegienerweiterung ohne Sonderrechte für die Schwachstelle CVE-2026-53365 im Linux-Kernel, der im August 2026 von Maher Azzouzi veröffentlicht wurde, der als Melder des Upstream-Fixes genannt wird. Der Name bezieht sich auf den Exploit und die dazugehörige Dokumentation und nicht auf eine separate Schwachstelle.

Der anfällige Code befindet sich im „Virtio vsock Zerocopy“-Sendepfad. AF_VSOCK wird üblicherweise mit der Kommunikation zwischen einem Gast und seinem Hypervisor in Verbindung gebracht, sodass man zunächst annehmen könnte, dass es sich um ein Virtualisierungsproblem handelt. Dies ist jedoch nicht der Fall. Linux stellt über den „vsock_loopback“-Transport eine lokale vsock-Kontext-ID bereit, nämlich VMADDR_CID_LOCAL (CID 1), und der Proof-of-Concept nutzt diesen Endpunkt, um mit demselben System zu kommunizieren. Zwischen einem normalen Benutzerkonto und dem anfälligen Code befinden sich weder ein Hypervisor noch ein Gast, noch ein Benutzer-Namespace noch eine Capability-Prüfung.

Die Voraussetzung ist also nicht die Kontrolle über einen Hypervisor. Es geht vielmehr um die Möglichkeit, eine Binärdatei als normaler lokaler Benutzer auf einem betroffenen Kernel auszuführen, auf dem die erforderlichen Funktionen verfügbar sind. Bei Shared-Hosting-Lösungen, mandantenfähigen Build-Systemen, CI-Runner und Jump-Hosts trifft dies auf die meisten Konten auf dem Server zu.

Das zweite tragende Element ist „io_uring“. Der Exploit nutzt registrierte Puffer in Verbindung mit dem „Zerocopy“-Versand, und genau dieses Zusammenspiel verwandelt einen Fehler bei der Seitenverwaltung zunächst in einen Referenz-Unterlauf und anschließend in Root-Rechte.

Auch der Zeitpunkt spielt eine Rolle. Der Patch ist bereits seit dem 14. Mai 2026 öffentlich zugänglich; verfasst wurde er von Stefano Garzarella von Red Hat, und der Exploit tauchte etwa drei Monate später auf. Niemand wurde hier überrumpelt, was auch bedeutet, dass jeder nicht gepatchte Kernel ein ganzes Quartal lang einem veröffentlichten Patch ausgesetzt war.

So funktioniert der Root-Exploit „VsockDrop“

Bei einem MSG_ZEROCOPY-Sendevorgang wird die Nutzlast nicht kopiert. Der Kernel sperrt die Benutzerseiten, überträgt Daten aus diesen Seiten und benachrichtigt den Benutzeraum später über die Fehlerwarteschlange, sobald diese Seiten wieder sicher verwendet werden können. Das Objekt, das all dies verwaltet, ist „ubuf_info“, das üblicherweise als „uarg“ bezeichnet wird.

Bei „Zerocopy“ begrenzt der VSOCK-Sendepfad jeden Socket-Puffer auf 64 KiB, sodass alles, was größer ist, fragmentiert wird. Vor der Korrektur wurde das uarg nur an den letzten Puffer in der Schleife angehängt. Frühere Puffer enthielten weiterhin festgelegte Seiten, ohne den vom Kernel dort erwarteten Abschlussstatus.

Das allein führt zu dem in der CVE beschriebenen Problem bei der Ressourcenabrechnung. Dem Userspace wird nie mitgeteilt, dass diese Seiten frei sind, und wenn die Sendeschleife vorzeitig abgebrochen wird, wird das uarg überhaupt nicht zugewiesen.

Bei mit io_uring registrierten Puffern sind die Folgen anders. Diese Seiten sind bereits langfristig fixiert, und der Netzwerkstack markiert die Fragmente als verwaltete Referenzen, was bedeutet, dass der Freigabeprozess sie unberührt lassen sollte. Die Schutzmaßnahme, die dies durchsetzt, ist Teil einer Prüfung, ob dem Puffer ein „uarg“ zugeordnet ist. Fehlt ein „uarg“, schlägt die Prüfung fehl, die Schutzmaßnahme wird nie aufgerufen, und die „unref“-Schleife ruft „put_page()“ für Fragmente auf, die nie eine Referenz erhalten haben. Das Ergebnis ist eine Verringerung der Anzahl der verirrten Seitenreferenz bei jedem Sendevorgang.

Wird dieselbe Nutzlast über ein gewöhnliches `iovec` gesendet, tritt nichts davon auf. In diesem Fall nimmt `io_uring` die richtigen Referenzen auf, die Abrechnungswerte stimmen überein, und es bleibt lediglich das Speicherleck übrig. Kein `io_uring`, kein Unterlauf.

Von da an sieht die Rechnung nicht gut aus. Die Pin-Vorgabe beträgt 1024, eine feste ABI-Konstante, sodass eine bekannte Anzahl von Sendevorgängen bei jedem betroffenen Kernel einen bekannten Teil des Referenzzählers aufbraucht. Man registriert einen Puffer, hebt die Zuordnung auf, sendet so lange, bis der Zähler Null erreicht, und der Kernel gibt eine Seite frei, auf die io_uring immer noch einen Pin hält. Liest man eine „kalte“ Seite von /usr/bin/su, gibt der Allokator genau diese physische Seite direkt als Seitencache zurück, da die Freelist nach dem Last-in-First-out-Prinzip funktioniert. Der noch registrierte Puffer bildet nun ein Alias für diesen Seitencache; ein festgelegter Schreibvorgang überschreibt den Pfad zum ELF-Interpreter, und die Ausführung von su veranlasst den Kernel, einen vom Angreifer bereitgestellten Interpreter zu laden, auf den bereits Root-Berechtigungen angewendet wurden.

In dieser Kette findet keine Ausführung von Kernel-Code statt. Es handelt sich um einen reinen Datenpfad zum Root-Recht, und falls Ihnen das Schema bekannt vorkommt, hat das auch seinen Grund. „Copy Fail“ (CVE-2026-31431) nutzte bereits Anfang 2026 ein ähnliches Prinzip, bei dem der Seitencache einer Setuid-Binärdatei manipuliert wurde, um Root-Rechte zu erlangen, ohne die zugrunde liegende Datei zu verändern. „VsockDrop“ erreicht ein ähnliches Ziel über einen ganz anderen Kernel-Fehler.

Ein Detail ist für jeden wichtig, der dies testet: Der Referenz-Drain ist deterministisch. Die Phase der Seitenrückgewinnung ist probabilistisch, und ein fehlgeschlagener Versuch kann beim selben Systemstart nicht wiederholt werden. Der Exploit ist also zuverlässig, ohne ein „One-Shot“-Exploit zu sein, und ein einziger fehlgeschlagener Durchlauf ist kein Beweis dafür, dass ein Kernel nicht betroffen ist.

Wurde bestätigt, dass „VsockDrop“ ausgenutzt werden kann?

Ja, auf einem betroffenen Ubuntu-24.04-Kernel ohne Konfigurationsänderungen.

TuxCare hat den öffentlich bekannten Exploit am 18. August 2026 unter Ubuntu 24.04 mit einem Azure-Kernel der Version 6.17 reproduziert. Der Durchlauf wurde von einem Konto ohne Sonderrechte aus gestartet und führte bereits beim ersten Versuch zu einer Root-Shell, ohne dass Anpassungen oder Neukonfigurationen vorgenommen wurden. Die einzige Begleiterscheinung war ein Eintrag „BUG: Bad page state“ in dmesg. Diese Image-Version enthält den Fix nicht, und Canonical hat noch keinen entsprechenden Fix veröffentlicht.

AlmaLinux 10.2 verhielt sich ganz anders. Der Exploit brach sofort mit der Fehlermeldung „io_uring init failed“ ab, was darauf hindeutet, dass die im Kernel vorinstallierte Standardeinstellung `io_uring_disabled = 2` genau ihre Aufgabe erfüllt. SELinux ist nicht der Grund dafür, falls diese Vermutung hier im Raum steht. Es gab keine AVC-Ablehnungen, und der Lauf schlug auch im permissiven Modus von SELinux fehl. Bei einer sysctl-Einstellung von 0 führte der nächste Versuch zu Root-Rechten, mit einem sauberen `dmesg` und ohne „oops“.

„Im Auslieferungszustand gemildert“ ist nicht dasselbe wie „behoben“.

AlmaLinux 9.8 ist ein Fall, bei dem Vorsicht geboten ist. Nach der erneuten Aktivierung von „io_uring“ lief der Exploit von Anfang bis Ende durch und schlug dann fehl, ohne Root-Rechte zu erlangen. Das ist kein eindeutiges negatives Ergebnis. Alle code-seitigen Voraussetzungen für den Underflow sind im ausgelieferten 5.14-Kernel vorhanden, der vom Exploit benötigte Zerocopy-Send-Opcode wurde in diese Kernel-Linie zurückportiert, und Red Hat stuft RHEL 9 weiterhin als betroffen ein. Die Fehlersignatur stimmte mit einem bekannten Fehlschlag auf einem Host überein, auf dem bereits Root-Rechte erlangt worden waren. Enterprise Linux 9 sollte im Code als betroffen behandelt werden, bis ein ordnungsgemäßer Test etwas anderes ergibt.

Ein fehlgeschlagener Versuch hinterlässt ebenfalls Spuren, die nützlicher sind, als es zunächst klingt. Der Exploit räumt erst bei Erfolg seine Spuren auf, sodass bei einem Fehlversuch die Dateien /tmp/loader und /var/tmp/.s zurückbleiben, wobei /var/tmp/.s mit setuid root versehen ist. Das ist ein Vektor zur lokalen Privilegienausweitung, der durch einen Versuch, der nicht einmal funktioniert hat, auf dem Host zurückgelassen wurde – und niemand schaut in /var/tmp nach. Entfernen Sie die Datei manuell.

Ein erfolgreicher Durchlauf unterbricht „su“ bis zum Neustart mit der Meldung „Kann nicht ausgeführt werden: Erforderliche Datei nicht gefunden“. Das Leeren der Caches hilft nicht, da die beschädigte Seite weiterhin einen Verweis enthält, sodass nur ein Neustart den Normalzustand wiederherstellt. Dies ist ein einfach zu erkennendes Anzeichen und stellt an sich bereits einen für den Benutzer sichtbaren Ausfall dar. Die Beschädigung verbleibt im Seitencache, und unter AlmaLinux ergab „rpm -V util-linux-core“ anschließend keinen Fehler, sodass die Binärdatei auf der Festplatte unberührt blieb. Bei einem Copy-on-Write-Dateisystem trifft dies möglicherweise nicht zu, wie der Autor des Exploits selbst warnt.

Ist Ubuntu 24.04 anfällig für VsockDrop?

Ja. Die betroffenen Kernel-Versionen von Ubuntu 24.04 sind anfällig, und der öffentlich zugängliche Root-Exploit konnte unter Ubuntu 24.04 ohne Konfigurationsänderungen reproduziert werden.

Canonical führt derzeit CVE-2026-53365 als Sicherheitslücke in den Noble-Kernel-Paketen auf, darunter die 6.8-GA-Reihe und die 6.17-HWE-Reihe sowie die Varianten für AWS, Azure, GCP und GKE. Ubuntu 22.04 mit dem 6.8-HWE-Kernel wird ebenfalls als anfällig aufgeführt, und dies ist die größere Installationsbasis der beiden.

Ubuntu ist von größerer Bedeutung, als es die Liste der betroffenen Pakete vermuten lässt, da die standardmäßige Konfiguration von „io_uring“ die Voraussetzung für die Ausnutzung der Sicherheitslücke offen lässt. Canonical stuft die CVE zudem als „mittel“ ein, weshalb für diese Zeilen keine Sicherheitsmitteilung herausgegeben wurde.

An den neueren, auf 7.0 basierenden Kerneln wird separat gearbeitet. Canonical listet derzeit sowohl Ubuntu 26.04 als auch die Ubuntu 24.04 HWE 7.0-Reihe als anfällig auf, wobei an Korrekturen gearbeitet wird. Überprüfen Sie daher den genauen Paketstatus, bevor Sie davon ausgehen, dass eine der beiden Versionen bereits korrigiert wurde.

Welche Linux-Systeme sind betroffen?

Nur die Situation auf der Upstream-Seite ist einfach. Die vsock-MSG_ZEROCOPY-Änderungen, die dieses Verhalten verursacht haben, wurden in Linux 6.7 integriert, und die stabilen Korrekturen sind in den Versionen 6.12.97, 6.18.34, 7.0.11 und 7.1 enthalten. Distributionen müssen anhand der Sicherheitshinweise und Pakete geprüft werden, da Anbieter Funktionen ständig zurückportieren. RHEL 9 gibt einen auf 5.14 basierenden Kernel an, der numerisch älter ist als 6.7, und Red Hat stuft RHEL 9 und RHEL 10 weiterhin als betroffen ein, ohne dass ein Fix ausgeliefert wurde, da die Funktion in diese Kernel-Reihe zurückportiert wurde.

Durch Backports werden sowohl anfällige Funktionen als auch Korrekturen in Versionsnummern übernommen, die nicht mit denen des Upstreams übereinstimmen. Betrachten Sie „uname -r“ daher als Anhaltspunkt für die Suche und nicht als endgültiges Urteil.

Was Enterprise Linux 9 und 10 schützt, ist diese Standardeinstellung und nicht etwa ein Patch; sie ist in den Kernel kompiliert und wird nicht als sysctl-Datei ausgeliefert. Daher übernimmt jedes System, das mit diesem Kernel bootet, diese Einstellung, sofern sie nicht anschließend im Userspace geändert wird. Datenbank-, Proxy- und Container-Workloads ändern sie bewusst – wodurch die Sicherheitslücke auf diesen Hosts nicht mehr hypothetisch, sondern real ist.

So beugen Sie einem VsockDrop vor

Die vorgestellte Kette benötigt registrierte io_uring-Puffer und einen vsock-Transport, der Zerocopy zulässt. Wird eine dieser Voraussetzungen entfernt, funktioniert sie nicht mehr – was immer noch eine bessere Ausgangslage ist, als man es bei den meisten Kernel-Fehlern gewohnt ist. Keine der beiden Maßnahmen ist jedoch ein Ersatz für die Behebung des Kernel-Fehlers.

1. Behalten Sie die Einstellung „io_uring denied“ bei. Unter Enterprise Linux 9 und 10 ist der Wert 2 bereits der Standardzustand, daher handelt es sich hierbei eher um eine Überprüfung als um eine Änderung. Ändern Sie diese Einstellung nur, wenn eine bestimmte Arbeitslast „io_uring“ tatsächlich erfordert.

Bei Ubuntu ist es genau umgekehrt. Das Deaktivieren von „io_uring“ führt dort zum Verlust von Funktionen, auf die laufende Anwendungen möglicherweise angewiesen sind, darunter Datenbanken, Proxys und Speicher-Software mit hohem Durchsatz. Betrachten Sie dies daher als eine echte betriebliche Änderung mit erheblichen Auswirkungen. Es ist zudem die einzige Laufzeitoption, die diesen Systemen zur Verfügung steht, bis ein Fix vorliegt. Wenn ein bestimmter Dienst „io_uring“ benötigt, ermöglicht ein Wert von 1 in Kombination mit „kernel.io_uring_group“ die Nutzung nur für Mitglieder dieser Gruppe, und ein Wert ungleich 2 sollte nicht als gleichbedeutend mit einer vollständigen Deaktivierung interpretiert werden.

2. Entfernen Sie den vsock-Transport, wenn er nirgendwo benötigt wird. Auf Bare-Metal-Systemen ohne vsock-Nutzer verläuft das Aufnehmen des Moduls in die Blacklist in der Regel reibungslos.

lsmod | grep -E 'vsock|vmw_vsock'

Wenden Sie dies nicht blindlings auf eine Maschine an, die selbst ein Gast ist. Sowohl der QEMU-Gastagent als auch VMware Tools nutzen vsock-Transporte, ebenso wie verschachtelte Virtualisierung und alle Lösungen im Firecracker-Stil. Bereits geladene Module müssen mit „rmmod“ entfernt oder ein Neustart durchgeführt werden, bevor eine Blacklist Wirkung zeigt. Überprüfen Sie daher anschließend, ob das Modul tatsächlich entfernt wurde.

Keine der beiden Schutzmaßnahmen wurde im Hinblick auf diesen konkreten Exploit getestet; betrachten Sie sie daher eher als Beseitigung der Voraussetzungen denn als nachgewiesene Abwehr.

Die VsockDrop-Korrektur

Die vorgelagerte Korrektur ist der Commit ae38d9179190 mit dem Titel „vsock/virtio: Behebung eines Problems beim Abschluss von Zerocopy-Vorgängen bei Sendevorgängen mit mehreren SKBs“ und orientiert sich an der Vorgehensweise von TCP.

Anstatt das uarg erst mitten in der Sendeschleife zu erstellen und es an den jeweils letzten Puffer anzuhängen, wird es bei der Korrektur im Voraus zugewiesen, an jeden Puffer mit einer pro Puffer ermittelten Referenz angehängt und die anfängliche Referenz anschließend ausgeglichen. Bei jedem Abschluss wird der Zähler verringert, die Benachrichtigung wird erst ausgelöst, wenn der letzte Puffer freigegeben ist, und ein Sendevorgang, der fehlschlägt, ohne etwas zu übertragen, bricht das uarg sauber ab.

Damit werden beide Probleme auf einmal gelöst. Jeder Puffer enthält nun ein uarg, sodass die Schutzmechanismen für verwaltete Fragmente im Freigabepfad so berücksichtigt werden, wie es ursprünglich vorgesehen war, und die verirrten Referenzfehler treten nicht mehr auf. Der Aufwand für das Backporting hängt davon ab, wie stark sich der Kernel des jeweiligen Anbieters vom Mainline-Kernel entfernt hat.

Die Korrektur ist in den Upstream-Stable-Versionen 6.12.97, 6.18.34, 7.0.11 und 7.1 enthalten. Hersteller-Kernel können dieselbe Korrektur unter völlig anderen Versionsnummern enthalten.

Status des Patches für CVE-2026-53365 ohne Neustart

Stand 18. August 2026 arbeitet das KernelCare-Team an Live-Patches für die meisten betroffenen Distributionen, die ohne Neustart installiert werden können. Die ersten Patches werden voraussichtlich innerhalb von 48 Stunden bereitgestellt.

Wenn Patches eintreffen, werden sie beim nächsten planmäßigen Durchlauf oder auf Abruf bereitgestellt.

kcarectl --update

Überprüfen Sie anschließend, welche Komponenten der laufende Kernel tatsächlich enthält.

kcarectl --patch-info | grep 'CVE-2026-53365'

Falls dabei keine Ergebnisse zurückgegeben werden, sollte das Fehlen dieser Informationen weder als Abdeckung noch als Lücke interpretiert werden. Vergewissern Sie sich vor dem Entfernen einer vorübergehenden Abhilfe beim Support, um welchen Kernel es sich genau handelt – nicht erst danach. Der Zeitstempel der Patch-Erstellung ist ein schwächeres sekundäres Signal und sollte nicht als Beweis für eine bestimmte CVE gewertet werden.

Erfahren Sie, wie KernelCare kritische Kernel-Sicherheitslücken ohne Neustart behebt → 

Häufig gestellte Fragen zu VsockDrop

Was benötigt ein Angreifer, um die Sicherheitslücke CVE-2026-53365 auszunutzen? Die Möglichkeit, eine Binärdatei als lokaler Benutzer ohne Sonderrechte auf einem betroffenen Kernel auszuführen, wobei io_uring verfügbar sein muss und ein vsock-Transport geladen werden kann. Kein Hypervisor, kein Gast, kein Benutzer-Namespace und keine spezielle Hardware.

Benötigt VsockDrop eine virtuelle Maschine? Nein, und genau das ist der Punkt, den die meisten Zusammenfassungen falsch darstellen. Der vsock_loopback-Transport ermöglicht es einem Prozess ohne Sonderrechte, über die lokale CID mit sich selbst zu kommunizieren, sodass auch ein Bare-Metal-Host ohne jegliche Virtualisierung weiterhin in Frage kommt.

Sind RHEL 9 und RHEL 10 von VsockDrop betroffen? Red Hat stuft beide als betroffen ein, einschließlich kernel-rt, wobei noch kein Fix bereitgestellt wurde. Der öffentlich zugängliche Exploit funktioniert in der bereitgestellten Form nicht, da diese Kernel „io_uring“ standardmäßig ablehnen; die Sicherheitslücke tritt daher nur dort auf, wo diese Standardeinstellung geändert wurde.

Kann CVE-2026-53365 aus der Ferne ausgenutzt werden? Nein. Dazu ist ein lokales Konto erforderlich. Das umfasst weiterhin Shared Hosting, mandantenfähige Build-Systeme, CI-Runner und jeden Host, auf dem ein Anwendungsbenutzer eine Binärdatei ausführen kann.

Wie lässt sich feststellen, ob jemand es versucht hat? Überprüfen Sie den Eintrag /var/tmp/.s, den ein fehlgeschlagener Versuch als setuid-Root-Binärdatei hinterlässt, sowie den Eintrag /tmp/loader. Ein fehlerhaftes „su“, das eine fehlende erforderliche Datei meldet, zusammen mit dem Eintrag „BUG: Bad page state“ in „dmesg“, deutet auf einen erfolgreichen Durchlauf bei diesem Systemstart hin.

Gibt es einen Patch für CVE-2026-53365? Upstream-Korrekturen sind in den Versionen 6.12.97, 6.18.34, 7.0.11 und 7.1 enthalten, und Debian hat Korrekturen für „trixie“ und für den „bookworm“-Kernel der Version 6.12 bereitgestellt. Canonical hat noch keinen Patch für die betroffenen Ubuntu-Versionen bereitgestellt, und zum Zeitpunkt der Erstellung dieses Artikels wurde noch kein Patch veröffentlicht, der eine Installation ohne Neustart ermöglicht.

VsockDrop-Zeitleiste

Referenzen

• Maher Azzouzi, Proof-of-Concept und technische Dokumentation zu VsockDrop, https://github.com/MaherAzzouzi/vsockdrop
• Linux-Upstream-Korrektur ae38d9179190, „vsock/virtio: Korrektur der Zerocopy-Abschlussbehandlung bei Senden mehrerer SKBs“, https://git.kernel.org/linus/ae38d9179190a956e2a87a69ef1dd6f451b51c4d
• Commit 581512a6dc93, „vsock/virtio: Unterstützung für das MSG_ZEROCOPY-Flag“, durch den der betroffene Code in Linux 6.7 eingeführt wurde
• Commit 1cb36e2522111, die Korrektur für die Erfassung festgesteckter Seiten, bei deren Überprüfung dieser Fehler zutage trat
• Red Hat CVE-2026-53365, https://access.redhat.com/security/cve/cve-2026-53365
• NVD CVE-2026-53365, https://nvd.nist.gov/vuln/detail/CVE-2026-53365
• Ubuntu CVE-2026-53365, https://ubuntu.com/security/CVE-2026-53365
• Debian CVE-2026-53365, https://security-tracker.debian.org/tracker/CVE-2026-53365