Die Schwachstelle hat einen CVSS-Wert von 7,8 und wurde von Asim Manizada am 28. Juli 2026 offengelegt. Nach seinen Angaben meldete er das Problem bereits am 19. Juni an security@kernel.org und die OVS-Maintainer. Der Upstream-Fix wurde am 24. Juli in die Stable-Zweige übernommen. Als erste korrigierte Upstream-Versionen nennt Manizada Linux 5.15.212, 6.1.178, 6.6.145, 6.12.97, 6.18.40 und 7.1.5. Für die ausgelaufenen Reihen 6.13 bis 6.17, 6.19 und 7.0 wird es keine Upstream-Stable-Fixes geben.
Entscheidend ist laut dem Forscher, dass reine Upstream-Versionsnummern nicht ausreichen, um die Betroffenheit zu beurteilen. Distributions-Kernel enthalten Backports und eigene Änderungen, deshalb seien die Tracker der jeweiligen Anbieter die verlässlichere Quelle. Ist das Open-vSwitch-Modul installiert, aber noch nicht geladen, kann bereits die Auflösung seines Generic-Netlink-Familiennamens das Modul automatisch nachladen. Ein leeres lsmod-Ergebnis bedeutet deshalb nicht, dass ein System sicher ist.
Technisch geht es um generierte Flow-Aktionen, die Open vSwitch als Netlink-Attribute speichert. Deren Feld nla_len ist 16 Bit breit und begrenzt ein einzelnes verschachteltes Attribut auf 65.535 Byte. Die fehlerhafte Zuweisung existierte laut Manizada seit 13 Jahren, blieb aber durch eine Obergrenze von 32 KiB für den gesamten erzeugten Aktionsstrom entschärft. Eine Änderung aus dem März 2025 entfernte diese Begrenzung, weil sie unvorhersehbare Fehler verursachte, unter anderem in großen OpenStack-Umgebungen, und legte damit den älteren Abschneidungsfehler frei.
Für die Ausnutzung wird eine CLONE-Aktion mit Hunderten Conntrack-Subaktionen eingereicht. Auf x86-64 erweitert der Kernel jede davon auf 164 Byte, sodass die erzeugte verschachtelte Aktion über 65.535 Byte hinauswächst. Beim Schreiben der Länge in das 16-Bit-Feld läuft der Wert über. Späterer Code vertraut dieser Länge und setzt das Parsen innerhalb von durch den Angreifer kontrollierten Conntrack-Daten fort, in denen präparierte OVS-Aktionen liegen. Weil dieser Einsprungpunkt innerhalb desselben zusammenhängenden Puffers deterministisch ist, ist laut Manizada kein Heap-Grooming nötig. Er bezeichnete das Ergebnis als Speicherfehler mit „der Zuverlässigkeit eines reinen Logikfehlers“.
Das veröffentlichte Proof-of-Concept kombiniert drei Primitive aus diesem Überlauf: ein Kernel-Zeigerleck über eine gefälschte OUTPUT-Aktion, ein beliebiges Kernel-Lesen über eine präparierte Tunnel-SET-Aktion und ein gezieltes Dekrement beim Abbau eines gefälschten tun_dst-Zeigers. Damit sucht der Exploit die Zugangsdaten eines Host-Prozesses und setzt auf modernen Kerneln fsuid und fsgid auf null herab. Das PoC ist laut Beschreibung ausdrücklich destruktiv. Es setzt außerdem OVS-Conntrack-Unterstützung, den FTP-Conntrack-Helper und eine installierte sudo-Umgebung voraus. Bei Erfolg korrumpiert es ein aktives Kernel-Credential, verändert /etc/sudoers.d oder /etc/sudoers, öffnet eine Root-Shell und lässt Prozesse sowie OVS-Zustand bestehen, um einen unsicheren Abbau zu vermeiden.
In seiner nicht abschließenden Testmatrix nennt Manizada eine erfolgreiche Ausnutzung unter Standardkonfigurationen auf 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, Kali 2026.1, Linux Mint 22.3, NixOS, openSUSE Tumbleweed, Pop!_OS, Rocky Linux 9 und 10 sowie Ubuntu 22.04. Auf getesteten Ubuntu-24.04-Systemen blockierte AppArmor die direkte Erzeugung von Namespaces, doch der Rückfallweg des PoC über aa-exec -p trinity stellte die Erreichbarkeit wieder her. Ubuntu 26.04 unter Standardkonfiguration blockierte den Weg für gewöhnliche Nutzer; nach Deaktivierung der AppArmor-Beschränkung für User-Namespaces waren die getesteten Systeme ausnutzbar. Nicht ausnutzbar über diesen Weg waren in den Tests Amazon Linux 2, Debian 11, Rocky Linux 8 und Ubuntu 20.04.
Als kurzfristige Gegenmaßnahme empfiehlt Manizada, einen gepatchten Anbieter-Kernel zu installieren. Wenn Open vSwitch nicht benötigt wird, sollte das Laden des Moduls blockiert werden. Ist das Modul bereits im Speicher, muss es entladen oder das System neu gestartet werden. Das Abschalten unprivilegierter User-Namespaces unterbindet den Weg für gewöhnliche lokale Nutzer, blockiert aber keinen Container oder anderen Prozess, der bereits CAP_NET_ADMIN über einen vom Angreifer kontrollierten Netzwerk-Namespace besitzt. Die Richtung über Container bezeichnete Manizada als theoretisch erreichbar, demonstrierte sie aber nicht im veröffentlichten PoC. Das Repository enthält zudem einen Notfall-BPF-Schutz für Umgebungen, die sowohl OVS als auch Namespaces aktiv halten müssen. CloudLinux betonte in seinem Hinweis, das Risiko sei besonders hoch, wenn sich mehrere Nutzer oder nicht vertrauenswürdige Workloads einen Host teilen.