LONDON (IT BOLTWISE) – Eine Memory-Corruption im Linux-Kernel-Datapath von Open vSwitch (CVE-2026-64531, CVSS 7,8) verschafft lokalen Nutzern einen Weg zu Root-Rechten. Die Schwachstelle heißt OVSwrap und nutzt einen Integer-Wrapper in Netlink-Attributlängen, um später Parsing-Schritte mit attacker-kontrollierten Daten zu triggern. Der zugehörige Proof-of-Concept ist ausdrücklich destruktiv und arbeitet für ungefähr 800 vorgefertigte x86-64-Kernel-Builds. In mehreren Distributionen ist ein unprivilegierter Pfad möglich – ein schneller Schutz ist das Blockieren des betroffenen Kernel-Moduls, falls ein gepatchter Vendor-Kernel noch nicht verfügbar ist.
Mit OVSwrap taucht eine Schwachstelle auf, die nicht in einem User-Space-Dienst von Open vSwitch sitzt, sondern im Kernel-Datapath selbst. In der Meldung wird CVE-2026-64531 als Memory-Corruption beschrieben, die auf breit verwendeten Standard-Konfigurationen einen Weg vom unprivilegierten lokalen Konto bis zu Root eröffnen kann. Entscheidend ist dabei der Kontext: Der Codepfad liegt in dem Moment offen, in dem Open vSwitch Flows in den Kernel installiert und dabei Netlink-Attribute verarbeitet. Laut der technischen Beschreibung wird damit nicht vorausgesetzt, dass bereits ein OVS-Bridge-Device existiert oder der Dienst ovs-vswitchd aktiv ist, und auch ein Host-Level mit CAP_NET_ADMIN ist für den Einstieg nicht nötig.
Technisch startet der Angriff in Umgebungen, in denen der Kernel-Datapath von Open vSwitch verfügbar ist und unprivilegierte User-Namespaces erlaubt sind. Ein normaler Nutzer kann dann per unshare -Urn private User- und Netzwerk-Namespaces anlegen, innerhalb des Namespaces CAP_NET_ADMIN erwerben und anschließend den verwundbaren Flow-Installation-Pfad erreichen. Zusätzlich kann es reichen, dass das openvswitch-Modul installiert, aber nicht geladen ist: Die Auflösung der Generic-Netlink-Familie kann das Modul automatisch nachladen, und eine leere lsmod-Ausgabe sagt in diesem Fall nichts über die Sicherheit aus. Genau hier liegt die operative Schwierigkeit für Administratoren: Selbst scheinbar „abgeschaltete“ Zustände können durch auto-loading wieder aktiv werden, sobald irgendein Prozess die benötigte Netlink-Familie anspricht.
Das Kernproblem wird über eine Längenverarbeitung in Netlink-Attributen greifbar. Open vSwitch speichert generierte Flow-Aktionen als Netlink-Attribute, wobei das Feld nla_len 16 Bit breit ist und damit eine maximale Größe von 65.535 Bytes pro verschachteltem Attribut erzwingt. Der Bericht ordnet ein, dass die unsichere Zuweisung lange existiert haben soll, aber ein zusätzlicher 32-KiB-Deckel auf den gesamten generierten Aktions-Stream dafür sorgte, dass ein „wrap“ in der Praxis seltener wurde. Eine Änderung im März 2025 habe diesen Deckel entfernt, weil er unvorhersehbare Fehler verursacht habe – inklusive Problemen in großen OpenStack-Setups – und dadurch die ältere Trunkierungslogik offengelegt. Für OVSwrap reicht dann ein speziell gepacktes CLONE-Aktions-Setup mit hunderten conntrack-Sub-Aktionen: Auf x86-64 expandiert der Kernel jede Subaktion in 164 Bytes, wodurch der generierte verschachtelte Aktionsbereich die 65.535-Byte-Grenze überläuft und der 16-bit-Wert anschließend wrappt.
Im nächsten Schritt vertraut späterer Kernel-Code auf die verdrehte Länge und setzt das Parsing deterministisch innerhalb desselben zusammenhängenden Puffers fort. Laut der Beschreibung wird dadurch kein „Heap-Grooming“ benötigt, weil das Landeziel im Speicher eindeutig vorhersagbar bleibt. Das Exploit-Chainning wird mit drei Primitiven skizziert, die aus dem Wraparound direkt folgen: ein Kernel-Pointer-Leak über eine gefälschte OUTPUT-Aktion, ein willkürliches Kernel-Read über eine gefälschte Tunnel-SET-Aktion und schließlich ein gezieltes Decrement über das Teardown eines gefälschten tun_dst-Zeigers. Im Ergebnis soll der Angreifer auf modernen Kerneln die fsuid- und fsgid-Werte bis auf 0 herunterzählen und damit die Rechte eines privilegierten Prozesses erlangen. Der veröffentlichte Proof-of-Concept wird als explizit destruktiv eingeordnet, was in der Praxis bedeutet: Tests sollten nur in isolierten Umgebungen erfolgen, weil der Ablauf einen „lebenden“ Kernel-Credential-Zustand korrumpieren und danach absichtlich unsicheren Teardown vermeiden kann, um Folgeschäden zu reduzieren.
Für das Timing ist relevant, dass upstream-Fixes laut Quelle am 24. Juli in stabilen Kernel-Zweigen gelandet sein sollen. Als erste fixe Releases werden Linux 5.15.212, 6.1.178, 6.6.145, 6.12.97, 6.18.40 und 7.1.5 genannt; zugleich wird darauf hingewiesen, dass End-of-Life-Serien wie 6.13 bis 6.17, 6.19 sowie 7.0 keine weiteren Upstream-Stable-Fixes erhalten. Gleichzeitig ist die Meldung vorsichtig: Distributionen übernehmen Backports und downstream-Änderungen, sodass allein die Upstream-Versionen nicht ausreichen. Wer schützen will, muss daher in der Praxis auf den Vendor-Tracker oder die konkrete Paketstrategie seiner Distribution schauen, statt nur auf eine Kernel-„5.xx“-Einstufung zu vertrauen.
Was Administratoren kurzfristig tun können, hängt von der eigenen Open-vSwitch- und Kernel-Situation ab. Wenn Open vSwitch nicht erforderlich ist, nennt der Bericht als schnellen Interimsschritt ein Blockieren künftiger Modul-Ladevorgänge: echo ‘install openvswitch /bin/false’ > /etc/modprobe.d/ovswrap.conf. Wichtig ist dabei die zweite Komponente: Ist das Modul bereits im Speicher, muss es entfernt oder durch einen Neustart ausgeräumt werden, denn ein „install“-Override stoppt nur zukünftige Ladeversuche. Das Deaktivieren unprivilegierter User-Namespaces schließt den gewöhnlichen lokalen Nutzerpfad zwar weitgehend, verhindert aber nicht automatisch Angriffsvarianten, in denen ein Prozess bereits über CAP_NET_ADMIN in einem Angreifer-kontrollierten Netzwerk-Namespace verfügt. Der Bericht beschreibt zudem eine Richtung hin zu Containern als theoretisch erreichbar, ohne sie im veröffentlichten Proof-of-Concept demonstriert zu haben; damit bleibt die Bedrohung in Umgebungen mit mehreren Nutzern oder untrusted Workloads besonders hoch, weil ein bereits kompromittierter Account das „Root-once“-Problem zu einem „Ganzes-System“-Problem machen kann.
Für die konkrete Angreiferverwertung liefert der veröffentlichte Proof-of-Concept weitere Hinweise auf die Praxisrelevanz. Laut Quelle enthält das Repository vorgefertigte Datensätze für ungefähr 800 exakte x86-64-Kernel-Builds und versucht darüber hinaus, nicht abgedeckte Builds dynamisch über Symbole oder BTF abzuleiten. Als getestete Default-Konfigurationen werden unter anderem AlmaLinux 9 und 10, Alpine 3.22 bis 3.24, Amazon Linux 2023, Arch, CentOS Stream 9 und 10, Debian 12 und 13, Fedora 42 bis 44, Gentoo sowie Kali 2026.1 genannt; zusätzlich werden distributionsbezogene Tests für Linux Mint 22.3, NixOS, openSUSE Tumbleweed, Pop!_OS, Rocky Linux 9 und 10 sowie Ubuntu 22.04 erwähnt. Auch Abwehrmechanismen werden adressiert: Auf getesteten Ubuntu 24.04-Systemen soll AppArmor direkte Namespace-Erstellung blockiert haben, ein aa-exec -p „Trinity“-Fallback habe aber die Erreichbarkeit wiederhergestellt; auf Stock-Ubuntu 26.04 soll der gewöhnliche Pfad durch AppArmor blockiert gewesen sein, während das Deaktivieren der AppArmor-User-namespace-Einschränkung die Systeme im Test wieder exploitable machte. Umgekehrt werden Ubuntu 20.04, Debian 11, Rocky Linux 8 und Amazon Linux 2 als Fälle beschrieben, in denen ältere Codepfade nicht über diesen Standardroute ausnutzbar waren.
Unterm Strich zeigt OVSwrap, wie schnell eine scheinbar „kleine“ Längenannahme in Netlink-Attributen in einer komplexen Netzwerk-Stack-Implementierung zu einer ernsthaften Rechteausweitung werden kann. Für Unternehmen heißt das: Der Sicherheitsstatus lässt sich nicht nur über „Open vSwitch ist aus“ bewerten, sondern über Kernel-Patches, das tatsächliche Modul-Ladeverhalten und die Runtime-Einstellungen zu User-Namespaces. Wer Cloud- oder Host-Plattformen betreibt, bekommt damit außerdem einen weiteren Grund, die Interaktion zwischen Netzwerkkomponenten und Kernel-Features wie Namespaces, CAP-Verteilung und Modul-Auto-loading als zusammenhängende Angriffsfläche zu betrachten. Bis Vendor-Patches greifbar sind, ist eine Kombination aus Modulblockade, Kernel-Upgrade-Plan und gezielter Prüfung der Namenspace-Policy der pragmatischste Weg, die lokale Eskalationskette zu unterbrechen.
💳 Amazon-Kreditkarte mit 2.000 Euro Limit bestellen!
🔥 Heutige Hot Deals bei Amazon: Bis zu 80% Rabatte!
🎉 Amazon Haul-Store für absolute Schnäppchenjäger!
- ★ 23-stufiges KI-Go-Training – Für Spieler mit Grundkenntnissen der Regeln – Entwickelt als intelligenter Trainingspartner passt sich die KI Spielern von 18K bis 9D an. Ideal für alle, die die Grundregeln bereits beherrschen und ihr Spiel verbessern möchten.
- IHR EMOTIONALER AI-BEGLEITER: Eiliko ist mehr als nur ein Anhänger, es ist ein charismatischer KI-Freund. Mit einem dynamischen LED-Bildschirm, der eine Vielzahl von animierten Gesichtern und Ausdrucksformen anzeigt, reagiert er auf Ihre Interaktionen mit einzigartiger Persönlichkeit und Charme.
- 【MEHR LEBEN FÜR DEINEN SCHREIBTISCH】 Lerne Eilik kennen – deinen kleinen Roboter-Freund mit Persönlichkeit. Mit liebevollen Animationen, ausdrucksstarken Reaktionen und spielerischen Interaktionen bringt Eilik mehr Freude in deinen Alltag. Ob auf dem Schreibtisch, im Büro oder am Nachttisch – Eilik wird schnell zu einem vertrauten Begleiter für besondere Momente.
- 【XL-Größe für gedeihende Pflanzen】Geben Sie Ihren Pflanzen den Raum, den sie verdienen! Unser verbessertes, großes 13,7 cm großes Design bietet Platz für Pflanzen mit einem Durchmesser von bis zu 8,9 cm und damit deutlich mehr Platz für Wurzelwachstum und Pflanzengesundheit im Vergleich zu kleineren, veralteten Modellen. Die Produktabmessungen betragen 13,6 x 13,6 x 13,2 cm und das Gerät wiegt nur 355 g.
- V28 Update - JETZT MIT NEUEN FUNKTIONEN! Als Reaktion auf das Ladeproblem von Loona haben wir das automatische Aufladen 2.0 verbessert. Diese Optimierung hilft Loona, die Ladewege in verschiedenen Szenarien zu erkennen und anzupassen, um die Erfolgsquote beim automatischen Aufladen zu erhöhen. Mobile Hotspots können sich mit Loona verbinden und überwinden WLAN-Einschränkungen, sodass Sie jederzeit und überall mit Loona interagieren können.
- Die besten Bücher rund um KI & Robotik!
- Die besten KI-News kostenlos per eMail erhalten!
- Zur Startseite von IT BOLTWISE® für aktuelle KI-News!
- IT BOLTWISE® kostenlos auf Patreon unterstützen!
- Aktuelle KI-Jobs auf StepStone finden und bewerben!
- Künstliche Intelligenz: Dem Menschen überlegen – wie KI uns rettet und bedroht | Der Neurowissenschaftler, Psychiater und SPIEGEL-Bestsellerautor von »Digitale Demenz«
Du hast einen wertvollen Beitrag oder Kommentar zum Artikel "OVSwrap: Open vSwitch-Datapath erlaubt lokales Root über Kernel-Memory-Corruption" für unsere Leser?
#Sophos
#AmazonPrime
#Bestseller
Es werden alle Kommentare moderiert!
Für eine offene Diskussion behalten wir uns vor, jeden Kommentar zu löschen, der nicht direkt auf das Thema abzielt oder nur den Zweck hat, Leser oder Autoren herabzuwürdigen.
Wir möchten, dass respektvoll miteinander kommuniziert wird, so als ob die Diskussion mit real anwesenden Personen geführt wird. Dies machen wir für den Großteil unserer Leser, der sachlich und konstruktiv über ein Thema sprechen möchte.
Du willst nichts verpassen?
Du möchtest über ähnliche News und Beiträge wie "OVSwrap: Open vSwitch-Datapath erlaubt lokales Root über Kernel-Memory-Corruption" informiert werden? Neben der E-Mail-Benachrichtigung habt ihr auch die Möglichkeit, den Feed dieses Beitrags zu abonnieren. Wer natürlich alles lesen möchte, der sollte den RSS-Hauptfeed oder IT BOLTWISE® bei Google News wie auch bei Bing News abonnieren.
Nutze die Google-Suchmaschine für eine weitere Themenrecherche: »OVSwrap: Open vSwitch-Datapath erlaubt lokales Root über Kernel-Memory-Corruption« bei Google Deutschland suchen, bei Bing oder Google News!