Unter Linux macht derzeit eine neue Schwachstelle Schlagzeilen: Die OVSwrap Linux Lücke im Open-vSwitch-Datapath kann – je nach Distribution und Konfiguration – von gewöhnlichen lokalen Benutzern zu Root-Rechten führen. Besonders kritisch ist die Lage, weil die Lücke mit einer öffentlichen Proof-of-Concept-Implementierung und bereits vorbereiteten Daten für viele Kernel-Builds bekannt geworden ist.
Die Schwachstelle trägt die Kennung CVE-2026-64531, ist als OVSwrap codiert und hat einen CVSS-Wert von 7,8. Der Sicherheitsforscher Asim Manizada hat sie am 28. Juli 2026 offengelegt.
Was ist die OVSwrap Linux Lücke genau?
Anders als man es bei „Open vSwitch“ erwarten könnte, sitzt das Problem im Kernel-Datapath und nicht im Userspace-Daemon ovs-vswitchd. Damit ist die Angriffsoberfläche eng an die Kernel-Komponente gekoppelt, die Datenpfade für Open vSwitch verarbeitet.
Manizada beschreibt in der technischen Analyse eine Reihe von Voraussetzungen, darunter: Angreifer benötigen keine bereits existierende OVS-Bridge, keinen laufenden ovs-vswitchd und auch keine Host-Berechtigung wie CAP_NET_ADMIN auf Systemebene.
Auf betroffenen Systemen, auf denen der Open-vSwitch-Kernel-Datapath verfügbar ist und unprivileged user namespaces aktiv sind, kann ein normaler Benutzer einen eigenen Satz aus User- und Netzwerk-Namespace aufbauen. Anschließend erhält er innerhalb dieses Namespace die Berechtigung CAP_NET_ADMIN und gelangt in den verwundbaren Pfad zur Installation von Flows.
Warum ist das besonders tückisch?
Ein wichtiger Punkt: Selbst wenn das Kernelmodul „openvswitch“ installiert, aber nicht geladen ist, kann es dennoch automatisch nachgeladen werden. Grund dafür ist die Auflösung des zugehörigen Generic Netlink family-Namens.
Außerdem gilt: Eine leere Ausgabe von lsmod ist kein Sicherheitsnachweis. Das System kann das Modul bei Bedarf nachladen – also muss man auf mehr achten als nur darauf, ob das Modul „sichtbar“ geladen ist.
Wie entsteht die Root-Fähigkeit?
Das Kernproblem ist eine Speicherbeschädigungs-Lücke durch einen Längen-„Wraparound“ bei Netlink-Attributen. Open vSwitch speichert generierte Flow-Aktionen als Netlink-Attribute, wobei das Feld nla_len nur 16 Bit breit ist. Damit ist die maximale Größe für ein einzelnes verschachteltes Attribut begrenzt: 65.535 Bytes.
Diese unsichere Zuordnung existierte bereits seit 13 Jahren. Damals verhinderten zusätzliche Begrenzungen, dass Werte in den Wraparound-Bereich geraten. Eine Änderung aus dem März 2025 entfernte jedoch diese Begrenzung des gesamten generierten Aktionsstreams. Dadurch wurden frühere Trunkierungsfehler wieder erreichbar – inklusive möglicher Ausfälle. In großen Umgebungen, etwa bei OpenStack, konnte das zu unvorhersehbaren Problemen führen.
Technisch passiert Folgendes: Ein Angreifer sendet eine CLONE-Aktion, die viele Conntrack-Subaktionen enthält. Auf x86-64 erweitert der Kernel jede Subaktion auf 164 Bytes. Dadurch kann der generierte, verschachtelte Aktionsblock die Grenze von 65.535 Bytes überschreiten. Beim Schreiben in das 16‑Bit-Längenfeld tritt ein Wraparound auf.
Später verlässt sich weiterer Code auf diese falsche Länge und setzt das Parsing innerhalb von Daten fort, die vom Angreifer kontrolliert werden. Laut Manizada ist dabei keine komplizierte Speicheraufbereitung (Heap Grooming) nötig, weil der Zielpunkt deterministisch innerhalb eines zusammenhängenden Puffers liegt.
Er ordnet die Zuverlässigkeit als „logic-bug-grade reliability“ ein – also als Fehler, der nicht nur theoretisch, sondern in der Praxis sehr wahrscheinlich ausnutzbar ist.
Welche Exploit-Kette wird im Proof-of-Concept genutzt?
Der öffentlich veröffentlichte Proof-of-Concept ist explizit zerstörerisch. Er setzt zudem mehrere Abhängigkeiten voraus: OVS-Conntrack-Unterstützung, den FTP conntrack helper sowie das Vorhandensein von sudo.
Die Angriffslogik nutzt drei Bausteine aus dem Wraparound:
- Kernel-Pointer-Leak über eine gefälschte OUTPUT-Aktion
- Arbitrary Kernel Read mittels einer konstruierten Tunnel SET-Aktion
- Gezielter Decrement über das Tear-down einer gefälschten tun_dst-Struktur
Diese Schritte führen dazu, dass Angreifer Zugangsdaten im Kernel finden und – auf modernen Kerneln – fsuid und fsgid auf 0 herunterzählen. Das entspricht letztlich Root-Rechten.
Im Erfolgsfall kann der Exploit eine Kernel-Credential-Struktur korrumpieren, Systemdateien unter /etc/sudoers.d oder /etc/sudoers verändern, eine Root-Shell öffnen und Spuren so weit reduzieren, wie es ohne unsichere Aufräumlogik möglich ist.
Die PoC-Sammlung enthält außerdem Datensätze für ungefähr 800 exakte x86-64 Kernel-Builds und versucht, für nicht exakt passende Builds anhand von Symbolen oder BTF eine Annäherung vorzunehmen.
Welche Linux-Distributionen sind in Tests besonders betroffen?
Manizadas Testmatrix zeigt, dass die Lücke in vielen Standardkonfigurationen ausnutzbar sein kann. Als Beispiele nennt er unter anderem AlmaLinux 9 und AlmaLinux 10, Alpine 3.22 bis 3.24, Amazon Linux 2023, Arch sowie CentOS Stream 9 und 10.
Außerdem werden Debian 12 und Debian 13, Fedora 42 bis 44, Gentoo, Kali 2026.1, Linux Mint 22.3, NixOS, openSUSE Tumbleweed, Pop!_OS und Rocky Linux 9 und 10 genannt. Auch Ubuntu 22.04 war in den Tests einbezogen.
Auf Ubuntu 24.04 blockierte AppArmor die direkte Namespace-Erstellung. Das Proof-of-Concept sah jedoch einen Fallback vor, der die Erreichbarkeit wiederherstellt. Für Ubuntu 26.04 beschreibt der Bericht, dass der „ordinary-user route“ durch AppArmor blockiert war; durch Deaktivieren der Einschränkung für unprivilegierte User Namespaces wurden die getesteten Systeme wiederum ausnutzbar.
Nicht ausnutzbar über diesen Weg waren laut Tests u. a. Amazon Linux 2, Debian 11, Rocky Linux 8 und Ubuntu 20.04. Hier hätten ältere Codepfade gegolten.
Fix und Prioritäten: Was Sie jetzt tun sollten
Die Upstream-Änderung wurde in den stabilen Kernel-Bäumen bereits am 24. Juli ausgeliefert. Wo ein gepatchter Vendor-Kernel noch fehlt, sollte man priorisiert handeln.
Upstream-Releases mit Fix
Zu den ersten Versionen mit enthaltenem Fix zählen Linux 5.15.212, 6.1.178, 6.6.145, 6.12.97, 6.18.40 und 7.1.5.
Wichtig: Stabil-Fixes kommen nicht mehr für die Reihen 6.13 bis 6.17, 6.19 bis sowie 7.0 (End-of-Life-Serien). Dennoch gilt: Die Upstream-Versionsnummern allein reichen oft nicht, weil Distributionen Backports und Downstream-Änderungen einpflegen.
Vendor-Tracker als sichere Quelle
Der Bericht betont, dass die Distributionstrecker die verlässlichere Grundlage sind. Prüfen Sie daher genau, ob Ihre Vendor-Version den Patch enthält – nicht nur anhand der Kernel-Release-Nummer.
Interim-Maßnahme: Module blockieren
Wenn Open vSwitch auf Ihrem System nicht zwingend erforderlich ist, empfiehlt sich als schneller Zwischenschritt, zukünftige Modul-Ladevorgänge zu verhindern. Als Beispiel nennt der Bericht:
echo ‚install openvswitch /bin/false‘ > /etc/modprobe.d/ovswrap.conf
Wichtig: Ein bereits geladenes Modul ist dadurch nicht „automatisch weg“. In dem Fall müssen Sie das Modul entladen oder das System neu starten, damit der Block greift.
User-Namespaces deaktivieren
Eine weitere Maßnahme ist das Abschalten von unprivileged user namespaces. Das schließt den beschriebenen lokalen Angriffsweg. Allerdings blockiert das nicht zwingend Szenarien, in denen ein Container oder ein anderer Prozess bereits CAP_NET_ADMIN über einen vom Angreifer kontrollierten Netzwerk-Namespace besitzt. Der Bericht nennt diesen Container-Weg als theoretisch erreichbar, zeigt aber in der veröffentlichten PoC keine praktische Demonstration dafür.
Warum betrifft das besonders Multi-User-Setups?
Das Risiko steigt deutlich, wenn mehrere Nutzer oder untrusted Workloads sich denselben Host teilen. So kann aus einer kompromittierten Teilkomponente eine vollständige Serverübernahme werden: Der Bericht vergleicht das Szenario damit, dass ein einzelnes Konto durch eine andere Schwachstelle Angreifer-Ressourcen bereitstellt – und OVSwrap Linux Lücke daraus einen „ganzen Server“-Vorfall machen kann.
Fazit
Die OVSwrap Linux Lücke (CVE-2026-64531) ist eine ernsthafte Kernel-Schwachstelle im Open-vSwitch-Datapath, die je nach Distribution und Konfiguration lokalen Benutzern Root-Zugriff ermöglichen kann. Da öffentliche PoCs verfügbar sind und viele Standard-Setups betroffen sein können, sollten Sie jetzt patchen – und falls noch kein Vendor-Fix verfügbar ist, zumindest Open vSwitch-Maschinenzugriffe über Module und User-Namespaces gezielt einschränken. Prüfen Sie dafür unbedingt die jeweiligen Distributionstreiber statt nur Upstream-Versionen.
Quelle: https://thehackernews.com/2026/08/new-ovswrap-linux-kernel-flaw-lets.html
