PwnEscape war 18 Jahre lang im Netzwerk-Stack des Kernels versteckt

Die Kurzfassung

Worum es geht: CVE-2026-99999, von dem der Forscher den Namen „PwnEscape“ verwendet, ist eine Schwachstelle in der Art und Weise, wie der Linux-Kernel IPv4-Prüfsummen für Pakete berechnet, die mit angehängten Offload-Metadaten eintreffen. Eine Gast-VM kann Offload-Metadaten für die Prüfsumme bereitstellen, die den Host dazu veranlassen, zwei Bytes in einen IPv4-Header zu schreiben, den der Kernel bereits validiert hat. Die CNA des Kernels veröffentlichte dies am 15. Oktober 2026.

Auswirkung: Speicher des Hosts gelangt in die vom Gast gesendeten Pakete, und laut Vercel wurde dieser Teil anhand seiner Produktions-Sandboxes demonstriert. Der Forscher brachte zudem Hosts zum Absturz und führte darauf Code als Root aus, allerdings nur auf seinen eigenen KVM- und Firecracker-Maschinen, die entsprechend der Konfiguration von Vercel eingerichtet waren.

Schweregrad: Der Kernel-CNA stuft die Schwachstelle gemäß CVSS 3.1 mit 9,3 als „kritisch“ ein, mit einem lokalen Angriffsvektor und einem geänderten Geltungsbereich. Auf einem Multi-Tenant-Host kann „lokal“ jedoch eine von einem Ihrer Kunden gemietete VM bedeuten, und der Schaden trifft den darunter liegenden Host.

Wer ist betroffen: Der anfällige Code stammt aus Linux 2.6.27 aus dem Jahr 2008. Es wird davon ausgegangen, dass Enterprise-Linux-Kernel von EL7 bis EL10 betroffen sind, darunter RHEL, AlmaLinux, Rocky Linux, Oracle Linux und CloudLinux, obwohl einzelne Kernel-Bäume noch nicht überprüft wurden. An erster Stelle stehen Hosts, auf denen Gäste laufen, über die sie keine Kontrolle haben, sowie gemeinsam genutzte Server, auf denen nicht vertrauenswürdige Benutzer über eine Shell verfügen. Unter EL8 bis EL10 ist /dev/kvm standardmäßig für alle schreibbar, sodass diese Benutzer möglicherweise eine eigene VM starten und von dort aus den Host angreifen können.

Status: Der Fix wurde am 14. Oktober in den Mainline-Kernel aufgenommen, und am 15. Oktober wurden sieben stabile Upstream-Kernel mit diesem Fix veröffentlicht. Bis zum 16. Oktober hatte noch keine Distribution einen entsprechenden Fix veröffentlicht. Es gibt keinen öffentlich zugänglichen Exploit-Code und keine Berichte über eine Ausnutzung in der Praxis. Es handelt sich um eine koordinierte Offenlegung, nicht um einen Zero-Day.

Gehen Sie sofort wie folgt vor: Deaktivieren Sie auf Hosts, auf denen nicht vertrauenswürdige Gäste laufen, die Prüfsummen-Offload-Funktion für die virtio-net-Schnittstellen dieser Gäste und nehmen Sie die damit verbundenen Einbußen beim Durchsatz in Kauf. Diese Einstellung hat keine Auswirkungen auf eine VM, die ein lokaler Benutzer für sich selbst startet. Deaktivieren Sie daher auf Hosts mit nicht vertrauenswürdigen Shell-Benutzern auch die Namespaces für nicht privilegierte Benutzer. Wenn Sie Ihre eigenen Kernel kompilieren, wechseln Sie zu einer festen, stabilen Upstream-Version.

Überprüfen Sie auf einem libvirt-Host die Definition eines Gastes auf explizite Prüfsummen-Einstellungen:

virsh dumpxml <domain> | grep ‘csum=’

Diese Attribute erscheinen nur dann im XML, wenn sie von jemandem festgelegt wurden. Bei einer Virtio-Schnittstelle bedeutet ein leerer Ausgabewert, dass die Standardwerte von QEMU gelten, und diese Standardwerte lassen die Prüfsummen-Offload-Funktion aktiviert.

Die Langfassung

Das Hosting von mandantenfähigen VMs basiert auf einem Versprechen: Was auch immer ein Kunde in seiner Gast-VM ausführt, bleibt in dieser Gast-VM. PwnEscape bricht dieses Versprechen durch einen Zwei-Byte-Schreibvorgang, den der Host-Kernel an sich selbst durchführt.

Das Besondere an dieser Schwachstelle ist ihr Auftreten. Sie befindet sich nicht in KVM und benötigt im Gegensatz zu Januscape und Zapscape, die Anfang dieses Jahres bekannt wurden, keine verschachtelte Virtualisierung. Die Schwachstelle liegt im normalen IPv4-Ausgabepfad des Hosts. Ein Gast gelangt dorthin auf dieselbe Weise, wie er es tausende Male pro Sekunde tut, indem er den Host auffordert, eine Prüfsumme für ihn zu berechnen.

Die Korrektur wurde bereits im Upstream-Kernel implementiert, die Distributionen haben diese jedoch noch nicht übernommen, während gleichzeitig ein ausführlicher Bericht zusammen mit der CVE veröffentlicht wurde. Solange diese beiden noch nicht aufeinander abgestimmt sind, sind die Hosts gefährdet.

Was diese Woche tatsächlich passiert ist

Paulos Yibelo von pwn.ai entdeckte den Fehler am dritten Tag der „Vercel Sandbox $1M Challenge“. Er meldete die Ursache am 4. September vertraulich an die Ansprechpartner für Kernel-Sicherheit und die Netzwerk-Betreuer, und Michael S. Tsirkin von Red Hat konnte den Fehler drei Tage später reproduzieren.

Die Patch-Reihe wurde am 19. September auf netdev veröffentlicht. Tsirkins enger gefasster Fix, Commit 6785011f8b16, wurde am 8. Oktober in den Networking-Tree übernommen und am 14. Oktober in die Mainline integriert – genau an dem Tag, an dem Vercel die Ergebnisse seiner Challenge veröffentlichte. Die CVE, sieben stabile Kernel-Versionen und der Bericht des Forschers, „PwnEscape: Guest-to-Host KVM Escape“, wurden alle am 15. Oktober veröffentlicht. Der Bericht erläutert den Fehler im Detail, enthält jedoch keinen Exploit-Code.

Wie aus zwei Bytes ein Speicherleck auf dem Host entsteht

Pakete, die über TAP, vhost-net oder AF_PACKET eingehen, können einen „virtio_net_hdr“ enthalten, einen kleinen Block mit Offload-Hinweisen des Absenders. Zwei dieser Hinweise, „csum_start“ und „csum_offset“, teilen dem Kernel mit, wo der Prüfsummenbereich beginnt und wo das Ergebnis abgelegt werden soll. Das Paket wird mit „CHECKSUM_PARTIAL“ gekennzeichnet, damit ein nachgeschalteter Prozess den Vorgang abschließt.

Die Schwachstelle liegt in der Eingabeprüfung. Die Funktion `virtio_net_hdr_to_skb()` prüft lediglich, ob `csum_start` mindestens 20 Byte tief im Puffer liegt. Bei TAP beginnt dieser Puffer mit dem 14-Byte-Ethernet-Header, sodass 20 Byte genau innerhalb des IPv4-Headers liegen. Es gibt keine Überprüfung, bei der `csum_start` mit dem Ende des IP-Headers abgeglichen wird.

Wenn der Host das Paket fragmentieren muss, ruft ip_do_fragment() die Funktion skb_checksum_help() auf, die die Prüfsumme berechnet und zwei Bytes an der Adresse csum_start + csum_offset schreibt. Der Gast liefert die Daten, für die die Prüfsumme berechnet wird, und hat somit die effektive Kontrolle über diese beiden Bytes. Der Schreibvorgang verlässt den Paketpuffer zu keinem Zeitpunkt. Die Daten landen in einem IP-Header, den der Kernel bereits analysiert, weitergeleitet und als vertrauenswürdig eingestuft hat.

Anschließend liest der Fragmentierer diesen Header erneut ein. Im Fall des Forschers änderte sich das erste Byte von 0x45 auf 0x4f – immer noch IPv4 –, doch das Feld „Header Length“ (ihl) gab nun 60 statt 20 Bytes an. ip_frag_next() kopiert diese Anzahl an Header-Bytes in jedes Fragment. Die gültigen linearen Daten des Pakets umfassten nur 28 Bytes – 20 Bytes Header und 8 Bytes Nutzdaten –, sodass die letzten 32 Bytes jeder Kopie aus dem Host-Speicher jenseits des Paketendes stammten. Sie verlassen den Host als IPv4-Optionen in den übertragenen Fragmenten, wo jeder vom Angreifer kontrollierte Empfänger sie lesen kann.

32 Byte sind nicht viel, aber das Leck wiederholt sich so lange, wie der Gast Daten sendet. Der Forscher kombinierte dies mit „Heap Grooming“, um ausgewählte 64-Byte-Schreibvorgänge in den Kernel-Speicher des Hosts zu erzielen, und führte anschließend auf dem Host als Root bei vier separaten Kaltstarts im Labor ein Hilfsprogramm aus. Diese Kette ist nicht öffentlich, und TuxCare hat nichts davon reproduzieren können.

Die Bewertung von 9,3 interpretieren

Der Vektor lautet AV:L/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:H, wobei insbesondere der Teil „AV:L“ für Verwirrung sorgt.

Entscheidend ist der geänderte Geltungsbereich. Der Angreifer befindet sich in einer Sicherheitsdomäne, dem Gast, während der Schaden in einer anderen, dem Host, entsteht. Genau diese Situation soll der CVSS-Geltungsbereich zum Ausdruck bringen, und deshalb erhält ein lokaler Fehler eine Bewertung von 9,3. Da das NVD zum Zeitpunkt der Erstellung dieses Artikels noch keine eigene Analyse veröffentlicht hatte, ist die CNA-Bewertung die einzige, die hier eine Rolle spielt.

Mindestens eine Schwachstellendatenbank listet dies bereits als aus der Ferne ausnutzbar auf. An sich ist dies jedoch nicht der Fall. CHECKSUM_PARTIAL und csum_start sind Metadaten zum Paketpuffer des Kernels, keine Bytes im Paket. Netzwerkkarten setzen diese Werte niemals anhand empfangener Daten. GRO kann sie zwar setzen, jedoch nur anhand eines TCP-Headers, den der Kernel selbst analysiert hat, und nur für IPv4-Pakete ohne IP-Optionen. Ein manipuliertes Paket aus dem Internet kann dort nicht hingelangen.

Ein Angreifer aus der Ferne benötigt zunächst einen Einstiegspunkt – in einem Gast, einem Container oder einem lokalen Konto. Auf einem Multi-Tenant-VM-Host kostet dieser Einstiegspunkt eine Kreditkarte.

Wer kann den Fehler beheben?

Das Hauptszenario ist ein nicht vertrauenswürdiger VM-Gast, der über TAP oder vhost-net auf den Host zugreift; dies wird sowohl in KVM- als auch in Firecracker-Konfigurationen demonstriert. Der Gast benötigt keinen Zugriff auf Host-Geräte, da der VMM bereits den TAP-Dateideskriptor hält und die Offload-Metadaten unverändert weiterleitet.

Die lokalen Pfade sind weniger eindeutig. Innerhalb eines Benutzer-Namespace kann ein Prozess ohne Sonderrechte möglicherweise „tun“ mit „IFF_VNET_HDR“ öffnen, da „tun“ die Berechtigung „CAP_NET_ADMIN“ nur innerhalb dieses Namespace überprüft, in dem der Prozess über diese Berechtigung verfügt. „AF_PACKET“ mit „PACKET_VNET_HDR“ ist ein ähnlicher Fall, da hierfür „CAP_NET_RAW“ erforderlich ist, das ebenfalls von einem Benutzer-Namespace gewährt wird. Keiner der beiden Fälle konnte reproduziert werden. Nicht privilegierte Benutzer-Namespaces, die unter EL8 und höher standardmäßig aktiviert sind, stellen hier den Hauptrisikofaktor dar, sind jedoch nicht der einzige. Der Zugriff auf ein vorhandenes „macvtap“- oder „ipvtap“-Gerät ist ein separater Weg mit eigenen Berechtigungsanforderungen. Gleiches gilt für eine VM, die der Benutzer für sich selbst startet. Unter EL8 bis EL10 lassen die standardmäßigen udev-Regeln /dev/kvm für alle schreibbar, sodass jeder lokale Benutzer eine solche VM starten und darin als Root agieren kann. Erhält diese VM ein TAP- oder vhost-net-Backend – typischerweise über einen Benutzernamensraum –, kann sie dem Host dieselben manipulierten Offload-Metadaten zuführen wie ein Gast-System eines Kunden. Shared-Hosting-Server fallen ebenfalls in den Geltungsbereich, selbst wenn auf ihnen niemals eine Kunden-VM ausgeführt wird.

Gemeinsam genutzte CI-Runner, die Kundencode in Rootless-Containern erstellen, sind aus diesem Grund einen Blick wert, auch wenn der lokale Pfad noch getestet werden muss.

Hosts, auf denen Gäste laufen, über die Sie keine Kontrolle haben, sowie gemeinsam genutzte Server, die nicht vertrauenswürdigen Benutzern eine Shell gewähren, haben Vorrang; danach folgen andere Systeme, auf denen nicht vertrauenswürdiger Code ausgeführt wird. Bei allen anderen Systemen ist das bekannte Risiko geringer, und sie sollten den Patch weiterhin über die üblichen Sicherheitspatches erhalten, deren Zeitpunkt sich nach dem tatsächlichen Risiko richtet.

Ist PwnEscape ein Zero-Day?

In Vercels Beitrag wird dies als Zero-Day-Schwachstelle im Linux-Kernel bezeichnet, und als Yibelo sie im August entdeckte, wusste niemand im Upstream-Bereich von ihrer Existenz. Als CVE-2026-99999 veröffentlicht wurde, war der Fix jedoch bereits in den Mainline-Kernel integriert. Für alle, die sich jetzt dazu äußern: Es handelt sich um eine koordinierte Offenlegung mit einem verfügbaren Fix, ohne öffentlichen Exploit-Code und ohne Berichte über eine Nutzung außerhalb autorisierter Forschungszwecke.

Der Forscher prognostiziert, dass innerhalb weniger Wochen funktionierende Exploits gegen schwächere Hypervisor-Konfigurationen und in weniger als einem Monat gegen Standard-Hypervisor-Konfigurationen auftauchen werden. Betrachten Sie dies als Prognose des Forschers. Betroffene Hosts sollten nicht abwarten, ob sich diese Prognose bewahrheitet.

Wer ist davon betroffen?

Status des Hersteller-Kernels zum 16. Oktober 2026, unabhängig vom Status des „KernelCare“-Patches ohne Neustart:

Lassen Sie sich vom Status der Distribution nicht durch den Befehl „uname -r“ täuschen. Enterprise-Kernel übernehmen Fehlerbehebungen, ohne ihre Basisversion zu ändern. Ein EL-Kernel, der älter als 5.10.272 erscheint, beweist daher in keiner Weise etwas. Nur eine Herstellerempfehlung oder ein verifizierter Patch für genau diesen Kernel, der ohne Neustart installiert werden kann, bringt Klarheit.

Holen Sie sich KernelCare noch heute →

Deaktivierung der Voraussetzungen, bis eine Lösung vorliegt

Jede der folgenden Optionen beseitigt eine Voraussetzung. Bislang wurde noch keine davon von TuxCare getestet; probieren Sie sie daher zunächst auf einem nicht kritischen Gast aus.

Für VM-Hosts ist es entscheidend, Gästen, denen Sie nicht vertrauen, keine Prüfsummen-Offload-Funktion anzubieten. Bei direkter Nutzung von QEMU nehmen Sie die Einstellung direkt auf dem Gerät vor:

-device virtio-net-pci,netdev=n0,csum=off,guest_csum=off

With libvirt, add <driver><host csum=’off’/><guest csum=’off’/></driver> inside the guest’s <interface> element. Either way it’s per VM, needs a full guest restart, and costs throughput because the guest loses TSO and GSO. Firecracker is the awkward case. It was one of the demonstrated targets, and whether offload can be switched off per VM there hasn’t been verified yet.

Deaktivieren Sie die Namespaces für Benutzer ohne Sonderrechte nur für den lokalen Pfad. Notieren Sie sich zunächst den aktuellen Wert mit `sysctl user.max_user_namespaces` und führen Sie anschließend folgenden Befehl aus:

sysctl -w user.max_user_namespaces=0

Dadurch werden neue Benutzernamensräume blockiert, bestehende bleiben jedoch unberührt. Um diese Einstellung dauerhaft zu speichern, legen Sie sie in einer Datei unter /etc/sysctl.d/ ab; zum Zurücksetzen löschen Sie diese Datei und setzen den alten Wert wieder ein. Diese Maßnahme hat jedoch erhebliche Nachteile: Sie führt zu Fehlfunktionen bei rootless Containern sowie bei den Sandboxen von Chrome und Flatpak und hat keinerlei Auswirkungen auf den Escape-Pfad des Gastes. Sollten nur vertrauenswürdige Konten VMs ausführen, schließt eine udev-Regel, die /dev/kvm für die Gruppe „kvm“ auf 0660 setzt, ebenfalls den „own-VM“-Weg ab – allerdings nicht den direkten „tun“-Weg.

Den laufenden Kernel patchen und überprüfen

Wenn Sie Ihre eigenen Kernel erstellen, wechseln Sie zu einer der in der Tabelle aufgeführten stabilen Versionen, bei denen der Fehler behoben wurde. Die Installation einer solchen Version hat keine Auswirkungen, bis der Host damit hochfährt. Überprüfen Sie daher, welche Version tatsächlich läuft:

uname -r

Ein Host, auf dem der neue Kernel installiert wurde, der aber nie neu gestartet wurde, läuft weiterhin mit der anfälligen Version, wobei Hypervisoren hier besonders häufig das Problem darstellen.

Sobald der KernelCare-Patch für Ihren Kernel freigegeben ist, kann er die Korrektur ohne Neustart anwenden. Sind automatische Updates aktiviert, wird er automatisch installiert, sobald er im Feed für den laufenden Kernel verfügbar ist, und „kcarectl –update“ fordert ihn bei Bedarf an. So überprüfen Sie die Abdeckung:

kcarectl –patch-info | grep „CVE-2026-99999“

Für die meisten Streams sind nun Patches verfügbar, die keinen Neustart erfordern (siehe Status oben). Sobald der Patch für Ihren Stream angewendet wurde, sollte der Befehl die CVE-Nummer des laufenden Kernels anzeigen. Solange dies noch nicht der Fall ist, sollten Sie die Abhilfemaßnahmen weiterhin beibehalten.

Dann ist da noch die Nacharbeit. Der Upstream-Fix ist klein: In sechs Dateien wurden 44 Zeilen hinzugefügt und 12 entfernt. Er fügt eine Hilfsfunktion hinzu, `ip_check_csum_start()`, die Pakete zurückweist, deren `csum_start` vor das Ende des IP-Headers zeigt, und ruft diese vor der Fertigstellung der Prüfsumme an fünf Stellen auf: IP-Fragmentierung, Bridge-Conntrack-Fragmentierung, `nfnetlink_queue`, `xt_CHECKSUM` und `xfrm`-Ausgabe. In der Commit-Meldung wird die Änderung als Maßnahme der „mehrschichtigen Verteidigung“ bezeichnet und es heißt: „Eine umfassendere Validierung bei der Eingabe ist in Vorbereitung.“ Rechnen Sie also mit einer zweiten Upstream-Korrektur und möglicherweise einem zweiten Patch, der keinen Neustart erfordert. Schließen Sie das Ticket für die erste Korrektur noch nicht.

Warum PwnEscape wichtig ist

Die Gastgrenze erstreckt sich weit über den Hypervisor hinaus. Jeder Teil des Host-Codes, der den Angaben des Gasts zu seinen eigenen Paketen vertraut, befindet sich darauf. Offload-Metadaten dienen der Beschleunigung, und 18 Jahre lang verließ sich der Kernel auf die Angaben des Gasts, wohin eine Prüfsumme gesendet werden sollte.

Wenn Sie virtuelle Maschinen anderer Benutzer ausführen, deaktivieren Sie ab sofort die Checksummen-Offload-Funktion bei nicht vertrauenswürdigen Gästen. Wenn Sie anderen Benutzern eine Shell zur Verfügung stellen, deaktivieren Sie die Namespaces für nicht privilegierte Benutzer. In jedem Fall sollten Sie den Fix in den laufenden Kernel integrieren, sobald einer für Ihren Kernel-Zweig verfügbar ist. Beobachten Sie anschließend weiterhin die Upstream-Entwicklung, da weitere Eingabevalidierungen geplant sind. Wenn ein Neustart des Hypervisors die vorherige Evakuierung der Gäste erfordert, soll der „rebootless“-Patch von KernelCare den Fehler im laufenden Kernel beheben, sobald er für Ihren Kernel verfügbar ist – ohne Evakuierung und ohne Wartungsfenster.

Holen Sie sich KernelCare noch heute →

Zeitleiste

Referenzen

Die Hauptquellen für diesen Beitrag sind der am 15. Oktober 2026 vom Kernel CNA veröffentlichte Eintrag CVE-2026-99999, Vercels Ergebnisse der „$1M Vercel Sandbox Challenge“ (14. Oktober 2026) sowie der Bericht des Forschers „PwnEscape: „Guest-to-Host KVM Escape“ (15. Oktober 2026), den Patch-Bericht des Forschers auf netdev, den Upstream-Fix 6785011f8b16, die LWN-Meldung zu den sieben stabilen Releases sowie den Eintrag im Debian-Sicherheits-Tracker.