Neue OVSwrap-Sicherheitslücke unter Linux gewährt lokalen Benutzern Root-Rechte auf Systemen mit Standardkonfiguration

Die Kurzfassung

Zur Langfassung springen ↓

Was es ist: CVE-2026-64531, auch bekannt als OVSwrap, ist eine lokale Rechteausweitung im Linux-Kernel im Aktionsvalidierungspfad von Open vSwitch. Ein 16-Bit-Längenfeld läuft über, wenn der Kernel eine übergroße verschachtelte Aktion aufbaut, und der Parser setzt das Einlesen innerhalb von durch den Angreifer kontrollierten Bytes fort, die dann als legitime Open-vSwitch-Aktionen verarbeitet werden. Zu diesem Abschnitt springen →

Auswirkung: Ein gewöhnlicher lokaler Benutzer kann Kernel-Zeiger offenlegen, Kernel-Speicher auslesen und einen gezielten Schreibvorgang ausführen. Der öffentlich zugängliche Proof-of-Concept verknüpft diese Schritte zu einem vollständigen Angriffspfad zur Manipulation von Anmeldedaten, der einen Eintrag in der sudoers-Datei schreibt und eine Root-Shell öffnet. Er enthält vorberechnete Offsets für rund 800 x86-64-Kernel-Builds. Zu diesem Abschnitt springen →

Schweregrad: Bei einem Schweregrad von 7,8 ist dies als hohe Priorität einzustufen. Für die Ausnutzung ist lediglich ein normales lokales Konto erforderlich – sonst nichts: keine Open-vSwitch-Konfiguration, kein laufender ovs-vswitchd-Dienst, keine OVS-Bridge, kein CAP_NET_ADMIN im ursprünglichen Namespace, kein Container mit erweiterten Rechten. Der Befehl „unshare -Urn“ stellt die Berechtigung innerhalb eines vom Angreifer erstellten Namespace bereit. Zu diesem Abschnitt springen →

Wer ist betroffen: Jeder betroffene Kernel, bei dem nicht privilegierte Benutzernamensräume zugelassen sind und das openvswitch-Modul zum Laden verfügbar ist. Dies ist bei den meisten Distributionen die Standardkonfiguration. Durch unsere eigene Backport-Analyse bestätigter Geltungsbereich: Enterprise Linux 9.7 und höher, Enterprise Linux 10.1 und höher, Debian 12 und 13, Ubuntu 22.04 und 24.04 sowie Amazon Linux 2023. Zu diesem Abschnitt springen →

Status: Kein Zero-Day. Am 19. Juni 2026 privat gemeldet und am 24. Juli in den stabilen Zweigen behoben. Der CVE-Eintrag und die Linux-CVE-Ankündigung wurden am 27. Juli veröffentlicht, gefolgt von der vollständigen Beschreibung und einem funktionierenden Exploit am 28. Juli. Es gibt keine öffentlichen Hinweise darauf, dass die Schwachstelle in der Praxis ausgenutzt wurde. Zu diesem Abschnitt springen →

Gehen Sie sofort wie folgt vor: Wenden Sie einen festen Hersteller-Kernel an und starten Sie den Rechner neu, oder installieren Sie den „KernelCare Rebootless Live Patch“ (der bereits automatisch bei Nutzern mehrerer Distributionen bereitgestellt wurde). Falls der Host Open vSwitch nicht verwendet, blockieren Sie das Modul vorläufig. Ein Hinweis: „apparmor_restrict_unprivileged_userns“ und die zugehörigen Sicherheitsoptionen für „userns“ in Debian und Ubuntu verhindern diese Kette nicht. Unser Kernel-Team hat sie getestet. Zu diesem Abschnitt springen →

Zu prüfen, ob das Modul geladen ist, ist nicht der richtige Test. Prüfen Sie, ob es auf der Festplatte für den laufenden Kernel vorhanden ist:

ls /lib/modules/$(uname -r)/kernel/net/openvswitch/openvswitch.ko* 2>/dev/null

Wenn dabei ein Pfad ausgegeben wird, ist der Host so lange angreifbar, bis der Kernel gepatcht oder das Modul blockiert wird – unabhängig davon, ob es bereits geladen wurde oder nicht.

Die meisten Hosts, auf denen OVSwrap eingesetzt wird, haben Open vSwitch noch nie bewusst betrieben. Genau das ist der Punkt, der die Teams auf die falsche Fährte führt.

OVS wird häufig mit softwaredefinierten Netzwerken in Verbindung gebracht: OpenStack, OVN, Kubernetes-CNIs, Virtualisierungsplattformen. Wenn keines dieser Elemente in Ihrem Stack enthalten ist, kann man davon ausgehen, dass diese CVE nicht relevant ist. Der anfällige Code ist jedoch in fast jeder gängigen Distribution als ladbares Modul im Standard-Kernel-Paket enthalten, und der Kernel lädt ihn bei Bedarf, sobald eine Anwendung danach fragt.

Ein Benutzer ohne Sonderrechte fordert dies an. Er erstellt einen privaten Benutzer- und Netzwerk-Namespace, der innerhalb dieses Namespaces die Berechtigung CAP_NET_ADMIN gewährt, und das reicht aus, um Open-vSwitch-Flows über die Netlink-Schnittstelle zu installieren. Durch die Anforderung wird das Modul automatisch in den Host-Kernel geladen. Keine Entscheidung des Administrators, keine Konfigurationsdatei, kein Daemon.

Die Aussage „Wir setzen Open vSwitch nicht ein“ bezieht sich also nicht auf die Sicherheitsrisiken. Es geht vielmehr darum, ob das Blockieren des Moduls zu Funktionsstörungen führen würde – das ist eine andere und viel relevantere Frage.

Ein weiterer wichtiger Punkt ist der zeitliche Ablauf. Der vorgelagerte Commit 3f1f75536668 wurde vier Tage vor der Veröffentlichung des Exploits in die Stable-Version übernommen, sodass Flotten mit kurzen Aktualisierungszyklen für den Stable-Kernel möglicherweise bereits abgesichert sind. Vier Tage sind zudem der gesamte Zeitraum zwischen „Patch verfügbar“ und „funktionierender Exploit mit Offsets für 800 Builds“.

Open-vSwitch-Aktionen werden als Netlink-Attribute übertragen. Jede beginnt mit einem „struct nlattr“-Header, der ein 16-Bit-Feld „nla_len“ enthält, das maximal 65.535 Byte darstellen kann.

Wenn OVS einen Datenfluss validiert, expandiert es verschachtelte Aktionen zu einem internen Aktionsstrom, den der Kernel selbst generiert. OVS_ACTION_ATTR_CLONE ist hier von Bedeutung, da es eine weitere Aktionsliste umschließt und sich daher verschachteln lässt. Der anfällige Code hat nie überprüft, ob ein generiertes verschachteltes Attribut noch in das 16-Bit-Längenfeld passte.

[Attacker enters a private user and network namespace]
|
v
[Attacker gains CAP_NET_ADMIN inside that namespace]
|
v
[Attacker installs a flow packing hundreds of conntrack
actions inside a CLONE wrapper]
|
v
[Generated nested action stream exceeds 65,535 bytes]
|
v
[Length is stored in the 16-bit nla_len field and wraps
to a small value]
|
v
[Parser resumes mid-stream, inside attacker-controlled data]
|
v
[Forged action headers are parsed as real OVS actions]
|
v
[Kernel read and constrained write primitives]
|
v
[Host-process credentials corrupted, root shell]

Der Exploit bündelt Hunderte von Conntrack-Aktionen in einem CLONE-Wrapper. Wenn OVS diese expandiert, wächst der generierte Datenstrom über die Kapazität von nla_len hinaus, der Wert wird abgeschnitten und auf einen kleinen Wert zurückgesetzt, und der Parser hält an der falschen Stelle an. Er setzt die Verarbeitung an einer Stelle im Datenstrom fort, die der Angreifer in Byte-Einheiten festgelegt hat und die so angeordnet ist, dass sie wie gültige Aktions-Header aussieht. Der Kernel verarbeitet diese als echte Aktionen.

Die einzigen wirklichen Einschränkungen sind die Anforderungen an die Erreichbarkeit: x86-64, ein OVS-Kernel-Datenpfad mit Unterstützung für Conntrack und FTP-Helper sowie die Erlaubnis zur Erstellung von Namespaces ohne Sonderrechte. Ein Standard-x86-64-Distributionskernel mit aktivierten rootless Containern erfüllt alle drei Anforderungen.

Die geschmiedeten Aktionen sind die Quelle der Primitive.

Falsche SET-Operationen im Tunnel führen zu einem Kernel-Zeiger-Leck und einem Lesezugriff auf den Kernel-Speicher. Ein separater Bereinigungspfad für das Tunnelziel ermöglicht einen eingeschränkten Schreibzugriff in Form einer gezielten Verringerung der Referenzanzahl um 32 Bit.

Ein einzelnes 32-Bit-Dekrement klingt zu schwach, um von Bedeutung zu sein – und für sich genommen ist es das auch. Erst in Verbindung mit den umgebenden Maßnahmen reicht es aus. Vor dem Betreten des Namensraums spaltet der Exploit einen Prozess ab, der auf der Host-Seite verbleibt. Anschließend richtet er das Dekrement auf die Anmeldedaten dieses Prozesses aus, und sobald der Prozess über privilegierte Rechte verfügt, schreibt er einen Eintrag in die sudoers-Konfiguration und startet eine Root-Shell.

Das Ergebnis ist eine zuverlässige Rechteausweitung statt eines Absturzes. In Kombination mit vorab berechneten Offsets für rund 800 Kernel-Builds ist der Aufwand, dies auf einem unterstützten Zielsystem zu reproduzieren, nahezu null.

Zwei Bedingungen entscheiden darüber, ob ein Host ausnutzbar ist, und beide sind fast überall standardmäßig aktiviert: Nicht privilegierte Benutzernamensräume sind zugelassen, und OpenVSwitch ist im Standard-Kernel-Paket enthalten, ohne dass eine Einschränkung für das automatische Laden vorliegt. Distributionen lassen Namensräume aktiviert, da rootless Podman, rootless Docker, Bubblewrap, Flatpak, nicht privilegiertes unshare(1) und die Sandbox von Chromium alle davon abhängig sind.

Der veröffentlichte Angriff erfordert nicht:

• Ein laufender ovs-vswitchd-Prozess
• Eine bereits vorhandene Open vSwitch-Brücke
• Etwaige frühere Open vSwitch-Konfigurationen
• CAP_NET_ADMIN im Host-Namespace
• Ein privilegierter Container
• Das Modul, das vor Beginn des Angriffs geladen werden muss

Das bedeutet, dass die Angriffsfläche größer ist als bei Hosts, auf denen OVS aktiv ausgeführt wird: Sie umfasst betroffene Systeme, auf denen das Modul lediglich für einen Benutzer ohne Sonderrechte zum Auslösen verfügbar ist, und die Tests des Forschers ergaben, dass dies auf die meisten getesteten Distributionen in ihrer Standardkonfiguration zutrifft.

Stellen Sie sich vor, wo das hinführt. Ein gemeinsam genutzter Build-Runner, der alles ausführt, was mit dem letzten Merge-Request hochgeladen wurde. Ein Multi-Tenant-Knoten, auf dem Kundencode unter einem gewöhnlichen Konto läuft. Eine Entwickler-Workstation mit Rootless-Containern und ein paar hundert Abhängigkeiten, die niemand gelesen hat. In jedem dieser Fälle verfügt der Angreifer bereits über das lokale Konto, und das benötigte Modul ist nur eine Netlink-Anfrage davon entfernt, sich selbst zu laden.

Die Entscheidung für jeden Gastgeber ist kurz und bündig:

• Wenn der Host OVS nicht verwendet und keine darauf laufenden Dienste von OVS-gestützten Bridges abhängig sind, sollte das Modul blockiert werden. Dadurch wird der anfällige Codepfad entfernt, anstatt lediglich einen Zugriffsweg darauf zu blockieren.
• Wenn der Host OVS verwendet – sei es als OVN- oder OpenStack-Neutron-Knoten, als Kubernetes-Cluster mit ovn-kubernetes oder Antrea oder als libvirt- oder oVirt-Host mit OVS-gestützten Bridges –, lassen Sie das Modul unverändert. Verweigern Sie stattdessen nicht privilegierten Benutzern Namespaces oder wenden Sie den Patch an.

Der Fehler ist alt, aber das Sicherheitslückenfenster ist es nicht

Zwei Daten sind entscheidend, und wenn man sie miteinander verwechselt, kommt man zu einer falschen Triage-Entscheidung.

Die unsichere Zuweisung zum Feld mit einer Länge von 16 Bit besteht seit etwa 13 Jahren. Während des größten Teils dieser Zeit begrenzte eine separate bedingte Obergrenze den generierten Aktionsstrom auf 32 KiB, wodurch verhindert wurde, dass eine Aktion jemals so groß wurde, dass sie den Wert von `nla_len` überschritt. Diese Obergrenze wurde im März 2025 aufgehoben, wodurch der latente Fehler ausnutzbar wurde.

Im Mainline-Kontext wurde das betroffene Fenster etwa mit Linux 6.14 geöffnet. Ältere Long-Term-Zweige wurden erst dann anfällig, als die Aufhebung der Begrenzung in sie zurückportiert wurde, und nicht bereits zum Zeitpunkt der Entstehung des ursprünglichen Fehlers.

Öffentlich bekannt gegebene Stabilitätsbereiche:

• 5.15.180 bis 5.15.211
• 6.1.132 bis 6.1.177
• 6.6.84 bis 6.6.144
• 6.18.0 bis 6.18.39
• 7.1.0 bis 7.1.4

Gemeldete „First-Fixed“-Veröffentlichungen: 5.15.212, 6.1.178, 6.6.145, 6.12.97, 6.18.40 und 7.1.5.

Hersteller-Kernel weichen in beide Richtungen vom Upstream-Kernel ab, daher sind die oben genannten Bereiche eher ein Ausgangspunkt als eine endgültige Antwort. Einige von RHEL abgeleitete 5.14-Kernel enthalten die aktivierende Änderung und sind betroffen, obwohl sie unterhalb aller in der Tabelle aufgeführten Bereiche liegen. Einige SUSE 6.12-Kernel haben die alte Obergrenze beibehalten und sind nicht betroffen, obwohl sie innerhalb eines Bereichs liegen.

Auch Unternehmensdistributionen portieren einzelne Commits zurück, ohne eine Upstream-Version zu übernehmen. Daher kann ein Kernel, dessen Version außerhalb des veröffentlichten Zeitfensters liegt, dennoch die anfällige Kombination enthalten. Das Zeitfenster wurde direkt in der Entwicklungsreihe 6.14 eingeführt und anschließend auf ältere Long-Term-Zweige ausgeweitet, als diese Änderung in diese zurückportiert wurde. Überprüfen Sie den Sicherheitshinweis oder den Patch-Status für den jeweiligen Distributionskernel.

Mit dem Commit a1e64addf3ff, „net: openvswitch: remove misbehaving actions length check“, wurde diese Begrenzung im März 2025 aufgehoben, da sie zu unvorhersehbaren Fehlern führte, weil OVS-Aktionen bei der Konvertierung in ihre interne Form an Größe zunehmen oder abnehmen können. Die Aufhebung der Überprüfung der Gesamtlänge war sinnvoll. Der Nebeneffekt war, dass nichts ein einzelnes verschachteltes Attribut daran hinderte, die Grenze von 65.535 Byte zu überschreiten.

Unsere Kernel-Analyse hat den anfälligen Pfad in den folgenden unterstützten Plattformfamilien bestätigt:

• Enterprise Linux 9.7 und höher
• Enterprise Linux 10.1 und höher
• Debian 12 (nur Versionen 6.1.132-1 und höher) und Debian 13
• Ubuntu 22.04 LTS und Ubuntu 24.04 LTS
• Amazon Linux 2023

Der Geltungsbereich von Enterprise Linux umfasst die entsprechenden RHEL-, AlmaLinux-, Rocky Linux- und CloudLinux-Kernel, sofern diese den betroffenen Code gemeinsam nutzen. CloudLinux 9 läuft mit dem AlmaLinux 9-Kernel und CloudLinux 10 mit dem AlmaLinux 10-Kernel, sodass beide direkt von dieser Sicherheitslücke betroffen sind.

Der Umfang der Abdeckung ist release- und variantenspezifisch. Leiten Sie nicht daraus ab, dass ein benachbarter Zweig anfällig oder bereits behoben ist, nur weil ein anderes Release derselben Distribution in der Liste aufgeführt ist.

Zwei Punkte sind noch offen und nicht eindeutig geklärt. Enterprise Linux 8 und CloudLinux 8, das eine eigene, von AlmaLinux 8 getrennte Kernel-Linie verwendet, wurden bislang weder bestätigt noch dementiert, ebenso wenig wie Ubuntu 20.04 und die älteren Long-Term-Zweige von Debian und Ubuntu. Bei allen stellt sich die Frage, ob sie den Backport zur Aufhebung der Obergrenze übernommen haben.

Eine Annahme bezüglich der Absicherung sollte man gleich zu Beginn verwerfen: Der Forscher berichtet, dass weder SELinux noch AppArmor im Test irgendeinen Schritt des Exploits blockiert haben – abgesehen von der User-Namespace-Richtlinie von AppArmor, die in einigen Ubuntu-Versionen die Erstellung von Namespaces verhindert, worauf weiter unten eingegangen wird. Der Enforcing-Modus ändert hier nichts am Ergebnis.

Warum gängige Einschränkungen im Benutzernamensraum möglicherweise nicht helfen

Das ist der Teil, der einem am ehesten das Wochenende kosten könnte.

Aktuelle Ubuntu-Versionen enthalten eine AppArmor-Richtlinie, die die Erstellung von Namespaces durch nicht privilegierte Benutzer einschränkt; diese wird über den Parameter `kernel.apparmor_restrict_unprivileged_userns` gesteuert. Dies ist die erste Einstellung, auf die die meisten Teams zurückgreifen, und sie blockiert tatsächlich den einfachen Befehl `unshare -Urn`: Unter Ubuntu 24.04 und 26.04 schlägt der direkte Versuch bei aktivierter Standardrichtlinie fehl.

Sie sollten sich nicht auf diese Sicherheitsmaßnahme verlassen. Ein öffentlich dokumentierter AppArmor-Bypass umgeht die Richtlinie in der Version 24.04, und in der Version 26.04 funktioniert der Exploit, sobald die Einschränkung deaktiviert ist. Unser eigenes Kernel-Team hat den anfälligen Pfad erreicht, obwohl die Sicherheitsoptionen von Debian und Ubuntu aktiviert waren. Betrachten Sie die Richtlinie als eine Art „Geschwindigkeitsbegrenzung“ auf dem Weg zu einem Patch.

Das vollständige Verwehren der Erstellung von Namespaces unterbricht tatsächlich die veröffentlichte Kette, da der Angreifer CAP_NET_ADMIN nicht mehr über „unshare -Urn“ erreichen kann. Die Steuerung, die dies bewirkt, ist die vorgelagerte:

# /etc/sysctl.d/99-ovswrap.conf
user.max_user_namespaces = 0

sudo sysctl --system

Verwenden Sie „user.max_user_namespaces“ anstelle von „kernel.unprivileged_userns_clone“. Letzteres ist ein veralteter Downstream-Patch aus der Debian-Familie, der unter Enterprise Linux überhaupt nicht vorhanden ist. Unter Ubuntu, wo beide möglicherweise vorhanden sind, kann die alleinige Einstellung des Schalters „unprivileged_userns_clone“ je nach Kernel-Version einen Restpfad zur Erstellung von Namespaces hinterlassen.

Überprüfen Sie den tatsächlich übernommenen Wert, da eine später sortierte Distributionsdatei in /usr/lib/sysctl.d/ stillschweigend Vorrang hat:

sysctl user.max_user_namespaces

Die Kompatibilitätsprobleme sind real. Rootless-Container-Tools funktionieren nicht mehr, das nicht privilegierte `unshare(1)` funktioniert nicht mehr und die Sandbox von Chromium funktioniert nicht mehr. In einer herkömmlichen Hosting- oder Datenbankumgebung fällt das niemandem auf. Auf Entwickler-Workstations und Container-Build-Hosts bemerkt man es jedoch innerhalb weniger Minuten.

Gibt es eine Umgehungslösung?

Die richtige vorübergehende Abhilfe hängt davon ab, ob der Host tatsächlich Open vSwitch verwendet. Keine der beiden Optionen ist ein Ersatz für die endgültige Behebung des Problems.

1. Deaktivieren Sie das Open vSwitch-Modul. Dies wird auf allen Hosts empfohlen, die OVS nicht verwenden – was auf die meisten Hosting-Flotten zutrifft. Überprüfen Sie zunächst mit dem Befehl „lsmod | grep openvswitch“, ob kein „ovs-vswitchd“-Prozess läuft. Anschließend:

# /etc/modprobe.d/99-ovswrap.conf
blacklist openvswitch
install openvswitch /bin/false

Die „install“-Zeile ist diejenige, die die eigentliche Arbeit erledigt. Ein Eintrag in der Blacklist allein verhindert nicht die vom Kernel selbst ausgelöste Modulabfrage bei Bedarf, und genau diesen Weg nutzt dieser Exploit – daher stellt die Aufnahme in die Blacklist allein in diesem Fall keine Abhilfemaßnahme dar. Beachten Sie, dass der Root-Benutzer eine „install“-Anweisung weiterhin mit „modprobe –ignore-install“ außer Kraft setzen kann und dass Module, die über das initramfs erzwungen werden, keiner der beiden Anweisungen unterliegen.

Die Regel blockiert nur das zukünftige Laden des Moduls. Befindet sich das Modul bereits im Speicher, werden alle davon abhängigen Prozesse beendet und das Modul entladen, was ebenfalls keinen Neustart erfordert:

sudo modprobe -r openvswitch

Die Moduldatei verbleibt auf der Festplatte, und „modinfo openvswitch“ gibt auch danach noch eine Ausgabe zurück. Das ist erwartet. Das Laden der Regel wird beendet; es wird nichts gelöscht.

Wenden Sie dies nicht auf OVN- oder OpenStack-Neutron-Rechen- und Netzwerkknoten, Kubernetes-Cluster, die ovn-kubernetes oder Antrea verwenden, oder auf libvirt- und oVirt-Hosts mit OVS-basierten Bridges an. Das Blockieren des Moduls an diesen Stellen führt zu einer Unterbrechung der Netzwerkverbindung.

2. Verweigern Sie nicht privilegierten Benutzern den Zugriff auf Namespaces. Verwenden Sie dazu die oben genannte sysctl-Einstellung „user.max_user_namespaces“. Diese funktioniert unabhängig vom Modulstatus und dient daher als Ausweichlösung für Hosts, auf denen tatsächlich OVS läuft – allerdings auf Kosten der bereits beschriebenen Funktionsstörung bei den „rootless-tooling“-Tools. Testen Sie dies zunächst mit Ihren Workloads.
3. Gehen Sie mit der BPF-Sicherheitsmaßnahme eines Drittanbieters vorsichtig um. Das öffentliche Exploit-Repository enthält eine Notfall-Sicherheitsmaßnahme auf BPF-Basis. Wir haben diese noch nicht getestet. Überprüfen und validieren Sie sie vor dem Einsatz in der Produktion auf repräsentativen Systemen und betrachten Sie sie nicht als gleichwertig mit einem Hersteller-Patch.

Entfernen Sie nach dem Patchen die Namespace-Einschränkung, falls diese nicht mehr benötigt wird:

sudo rm -f /etc/sysctl.d/99-ovswrap.conf

Der Modulblock kann bestehen bleiben. Er ist nicht an eine bestimmte Kernel-Version gebunden, überdauert Updates und Neustarts und sorgt auf einem Host, auf dem Open vSwitch nicht benötigt wird, dafür, dass ein Teil der Angriffsfläche geschlossen bleibt. Dokumentieren Sie dies, damit der nächste Benutzer weiß, warum das Netzwerk versagt, falls dieser Host jemals OVS benötigt, und entfernen Sie ihn dann mit dem Befehl „rm /etc/modprobe.d/99-ovswrap.conf“.

Die vorgelagerte Korrektur ist Commit 3f1f75536668, „net: openvswitch: Ablehnung übergroßer verschachtelter Aktionsattribute“.

Es fügt eine Validierung hinzu, die eine generierte verschachtelte Aktion zurückweist, deren Größe nicht sicher in `nla_len` dargestellt werden kann. Anstatt zuzulassen, dass ein zu großer Wert auf 16 Bit gekürzt wird, stoppt der Kernel die ungültige Aktion während der Validierung, bevor der fehlerhafte Datenstrom den Datenpfad erreicht.

Die Änderung erfolgt im Validierungspfad und nicht im Datenpfad-Fast-Path. Sie erfordert weder eine Migration der Kernel-Datenstrukturen noch einen persistenten Zustand pro Task, weshalb sie sich für Patches ohne Neustart eignet.

Den laufenden Kernel patchen und überprüfen

Durch die Installation eines aktualisierten Kernel-Pakets wird der im Speicher ausgeführte Kernel nicht gepatcht. Bei einem herkömmlichen Update gehen Sie wie folgt vor: Installieren Sie das korrigierte Paket für genau Ihre Distribution und Version, starten Sie den Rechner neu und vergewissern Sie sich, dass der korrigierte Kernel läuft.

uname -r

Vergleichen Sie dies mit der jeweils geltenden Sicherheitsempfehlung des Anbieters, nicht mit dem neuesten Paket auf der Festplatte. Und gehen Sie nicht davon aus, dass ein nach dem 24. Juli 2026 kompilierter Kernel den Fix enthält. Die Versionsnummern der Distributionen entsprechen nicht den Upstream-Releases; die Sicherheitslücke wurde durch ein Backport in diese Zweige übernommen, und die Korrektur wurde nach einem separaten Zeitplan zurückportiert.

Rebootloses Patchen

KernelCare wendet dieselbe Validierungslogik aus dem Upstream auf den aktiven Kernel an. Nach dem Patchen lehnt OVS übergroße, generierte verschachtelte Aktionen ab, bevor es zu einem Längenüberlauf kommt, ohne dass Open vSwitch deaktiviert, die Modulrichtlinie geändert oder die Workload neu gestartet werden muss. Es handelt sich um einen reinen Kernel-Fehler, bei dem keine Bibliothekskomponente im Userspace zu beheben ist.

Bei den meisten Bereitstellungen werden neue Patches automatisch im Hintergrund in festgelegten Intervallen – üblicherweise alle vier Stunden – abgerufen. So rufen Sie Patches bei Bedarf aus dem Produktions-Feed ab:

kcarectl --update

Falls sich ein Patch noch im Testprozess für Ihre Kernel-Familie befindet:

kcarectl --update --prefix test

Prüfen Sie anschließend, ob die CVE in den Informationen zum installierten Patch aufgeführt ist:

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

Vergewissern Sie sich, dass der Patch für genau den aktuell ausgeführten Kernel verfügbar ist, bevor Sie vorübergehende Abhilfemaßnahmen entfernen. Falls für Ihre Kernel-Familie noch kein Patch verfügbar ist, behalten Sie die Modulblockierung oder die Namespace-Einschränkung bei.

Erkennung und Überprüfung von Vorfällen

Es gibt keinen eindeutigen Indikator, daher sollten Sie alles hier eher als Anhaltspunkt denn als Beweis betrachten.

Das aussagekräftigste Anzeichen ist das Modul selbst. Auf einem Host, auf dem Open vSwitch keine legitime Verwendung findet, ist das Erscheinen von „openvswitch“ in „lsmod“ an sich schon ungewöhnlich, und es lohnt sich, die entsprechenden Audit-Protokolle zum Laden des Moduls oder die Journal-Einträge dazu genauer zu untersuchen. Dieses Anzeichen verschwindet, sobald Sie den „modprobe“-Block einsetzen; prüfen Sie die Situation daher, bevor Sie ihn anwenden.

Schauen Sie sich dann an, was der veröffentlichte PoC mit seinen Root-Rechten anstellt:

sudo stat /etc/sudoers /etc/passwd /etc/shadow
sudo find /etc/sudoers.d -maxdepth 1 -type f -printf '%TY-%Tm-%Td %TH:%TM:%TS %p\n'

Unerwartete Einträge in der `sudoers`-Datei oder neue Dateien unter `/etc/sudoers.d/` sind Überbleibsel des veröffentlichten Proof-of-Concept, wobei ein Angreifer mit Root-Rechten diesen Schritt jedoch vollständig überspringen könnte. Achten Sie außerdem auf neue oder neu privilegierte Konten, unerklärliche SSH-Schlüssel sowie die Erlangung von Berechtigungen ohne entsprechende `sudo`-, Anmelde- oder Authentifizierungsereignisse, da durch einen Kernel-Schreibvorgang manipulierte Anmeldedaten keine Authentifizierungsspur hinterlassen.

Weitere Anhaltspunkte im Verhalten: Nicht privilegierte Prozesse, die Benutzer- und Netzwerk-Namespaces erstellen, obwohl dies normalerweise bei keiner Arbeitslast der Fall ist; ein Prozess, der mit Root-Rechten läuft, der jedoch nicht als Root gestartet wurde und keine setuid-Vorgänger aufweist; sowie Kernel-Warnungen oder „Oops“-Meldungen aus dem OVS-Flow-Validierungspfad, die bei fehlgeschlagenen Versuchen auftreten können.

Wir haben den öffentlich zugänglichen PoC bislang noch nicht intern in eingeschränkten oder containerisierten Umgebungen nachgestellt. Gehen Sie daher nicht davon aus, dass eine Isolierung auf Benutzer- oder Containerebene den Angriff abwehrt, ohne diesen Systemaufrufpfad in Ihrer eigenen Umgebung getestet zu haben.

Nein. Das Problem wurde am 19. Juni 2026 vertraulich gemeldet, die Korrektur gelangte am 24. Juli im Rahmen einer koordinierten Veröffentlichungssperre in die stabilen Zweige, und der Bericht sowie der PoC folgten am 28. Juli. In der Offenlegung gibt es keinerlei Hinweise darauf, dass die Schwachstelle in der Praxis ausgenutzt wurde, bevor eine Korrektur vorlag.

Das bedeutet jedoch nicht, dass dies eine geringe Priorität hat. Sobald der Exploit öffentlich bekannt wurde, erhielten Angreifer einen getesteten Pfad von einem gewöhnlichen lokalen Konto bis hin zu Root sowie Offsets für eine große Anzahl von Kernel-Builds. Ein Vorsprung von vier Tagen hilft nur den Flotten, die stabile Kernel bereits schnell gepatcht hatten.

Warum CVE-2026-64531 von Bedeutung ist

Drei Details lassen dies leicht als Routinefall abhaken, und alle drei sind irreführend.

Es erfordert lokalen Zugriff, sodass es wie ein Problem der zweiten Stufe aussieht – nur dass Mieter, CI-Runner und nicht vertrauenswürdige Abhängigkeiten diesen lokalen Zugriff bereits haben. Es benötigt Open vSwitch, sodass es wie ein Nischenproblem im Netzwerkbereich aussieht – nur dass sich das Modul bei Bedarf selbst lädt. Und es benötigt einen Namespace für nicht privilegierte Benutzer, sodass es wie etwas aussieht, das durch bestehende Sicherheitsmaßnahmen bereits abgedeckt ist – nur dass die spezifischen Sicherheitsmaßnahmen, auf die die meisten Debian- und Ubuntu-Teams hier vertrauen, nicht funktionieren.

Die Versionshistorie liefert eine weitere Erkenntnis. Eine Änderung, durch die im März 2025 eine Größenbeschränkung aufgehoben wurde, verwandelte eine seit einem Jahrzehnt ruhende Zuweisung in eine aktive Privilegieneskalation, und sie gelangte als gewöhnlicher Backport – und nicht als Release – in die Langzeit-Zweige. Eine Triage-Warteschlange, die sich ausschließlich an den Upstream-Versionsnummern orientiert hätte, hätte diese Kernel als außerhalb des Zeitfensters liegend eingestuft.

Bei Systemen mit herkömmlichen Patches sollten Sie das Hersteller-Update installieren und sicherstellen, dass der Host damit erfolgreich hochfährt. Bei Systemflotten, bei denen Notneustarts ein eigenes Betriebsrisiko darstellen, schließt KernelCare den anfälligen Validierungspfad im laufenden Kernel, ohne die Systeme offline zu nehmen. So oder so ist die kostengünstigste Maßnahme derzeit die Sperrung des Moduls auf jedem Host, der OVS nicht nutzt: Diese Maßnahme ist reversibel, hat nur geringe Auswirkungen und beseitigt den Codepfad, anstatt ihn zu umgehen.

Holen Sie sich KernelCare noch heute →

Zeitleiste

Referenzen

• Asim Manizada, OVSwrap-Offenlegung, oss-security, 28. Juli 2026 und der Seclists-Mirror
• Technischer Bericht zu OVSwrap: https://heyitsas.im/posts/ovswrap
• Öffentlicher OVSwrap-Proof-of-Concept und BPF-Guard: https://github.com/manizada/OVSwrap
• Upstream-Linux-Korrektur 3f1f75536668, „net: openvswitch: Ablehnung übergroßer verschachtelter Aktionsattribute“
• Linux-CVE-Meldung zu CVE-2026-64531
• CVE-Eintrag, CVE-2026-64531
• Betroffene Sicherheitshinweise für RHEL, AlmaLinux, Rocky Linux, CloudLinux, Debian, Ubuntu und Amazon Linux