Een nieuwe kwetsbaarheid in de Linux kernel datapath rondom Open vSwitch maakt het mogelijk dat gewone lokale gebruikers, in bepaalde standaardconfiguraties, een route naar root kunnen krijgen. De bug heet OVSwrap Linux Open vSwitch (CVE-2026-64531) en heeft een CVSS-score van 7,8.
Het opvallende: de fout zit niet in de gebruikersruimte-daemon ovs-vswitchd, maar in de kernelcomponent die datapathverkeer verwerkt. Bovendien is er een openbare proof-of-concept (PoC) met vooraf voorbereide gegevens voor ongeveer 800 kernelbuilds op x86-64.
Wat is OVSwrap Linux Open vSwitch precies?
De kwetsbaarheid is door onderzoeker Asim Manizada openbaar gemaakt op 28 juli 2026. Technisch gezien betreft het een memory corruption probleem in de kernel-datapath van Open vSwitch. In de analyse wordt OVSwrap gekoppeld aan een specifieke CVE: CVE-2026-64531, met codenaam OVSwrap.
Manizada benadrukt dat de aanval niet draait om een bestaande OVS-bridge of een draaiende ovs-vswitchd daemon. Ook is er volgens de beschreven aanvalsvormen geen host-level CAP_NET_ADMIN nodig.
Voorwaarden: wanneer kan een lokale gebruiker root bereiken?
Op systemen waar de Open vSwitch kernel datapath beschikbaar is én waar unprivileged user namespaces ingeschakeld zijn, kan een lokale gebruiker met een reeks stappen alsnog in de kwetsbare flow-installatie terechtkomen.
Concreet beschrijft de publicatie dat een gebruiker met tools als unshare -Urn private user- en netwerk-namespaces kan opzetten. In die namespace kan de gebruiker vervolgens CAP_NET_ADMIN verkrijgen, waardoor toegang ontstaat tot een pad dat normaal alleen met meer privileges wordt verwacht.
Daarnaast speelt een extra subtiele factor mee: als de Open vSwitch kernelmodule geïnstalleerd is maar niet geladen, kan het automatisch laden worden getriggerd door het oplossen van een Generic Netlink family name. Een lege lsmod-output betekent dus niet automatisch dat het systeem veilig is.
Waarom is het gevaarlijk? De kern van het probleem
Volgens de technische onderbouwing slaat Open vSwitch gegenereerde flow actions op als Netlink-attributen. Het kwetsbare punt zit in de veldbreedte: de lengte nla_len is 16 bits, waardoor een enkele geneste actie maximaal 65.535 bytes kan bevatten.
Die truncation bestond al jaren, maar bleef tot een bepaald niveau “binnen de grenzen” door een eerdere totaal-cap op het gegenereerde actie-stream. Die bescherming werd in maart 2025 aangepast: de cap verdween omdat die soms tot onvoorspelbare fouten leidde, inclusief in grote OpenStack-omgevingen. Daarmee kwam de oudere truncatie-fout weer bloot te liggen.
De PoC werkt door een actiepakket aan te leveren met honderden sub-acties. Wanneer de kernel ze uitbreidt, groeit de geneste actie voorbij het 65.535-bytegrenspunt. Bij het wegschrijven naar het 16-bit-lengteveld ontstaat een wraparound. Vervolgens vertrouwt later kernelcode op die (verkeerd) berekende lengte en gaat parsing verder vanaf een plek waar zich data bevindt die door de aanvaller is voorbereid.
Manizada beschrijft de betrouwbaarheid als hoog: het gaat om “logic-bug-grade reliability”. Er is dus niet alleen sprake van een crash, maar een gerichte keten naar privilege-escalatie.
De exploitketen: van wraparound naar root
De gepubliceerde exploitketen gebruikt drie onderliggende mogelijkheden die samen het einddoel ondersteunen:
- Kernel pointer leak via een gefingeerde OUTPUT-actie.
- Arbitrary kernel read met behulp van een SET-actie voor een vervalste tunnel.
- Gerichte decrement door het afbreken/teardown van een vervalste pointerstructuur (tun_dst).
Met die primitives kan de exploit op moderne kernels uiteindelijk de fsuid en fsgid terugzetten naar 0. Daarmee kan de aanvaller privileges naar root brengen.
De PoC die is vrijgegeven wordt nadrukkelijk als destructief beschreven. Ook is er extra setup nodig: de PoC vereist onder meer OVS conntrack support, de FTP conntrack helper en sudo om bepaalde stappen te kunnen uitvoeren.
Impact in gedeelde omgevingen
De risico-inschatting wordt extra scherp zodra meerdere gebruikers of onbetrouwbare workloads dezelfde host delen. In zo’n scenario kan één gecompromitteerde account (door een andere kwetsbaarheid) de starter zijn, en OVSwrap is dan het “vergrotende effect” dat van een enkel incident een volledige systeemcompromittatie kan maken.
Dit sluit aan bij de manier waarop adviezen zulke ketenrisico’s framen: niet het bestaan van één fout is het ergst, maar het feit dat een lokale aanvaller daarna alsnog naar kernniveau kan escaleren.
Geteste omgevingen: welke distributies vallen op?
In een niet-uitputtende testmatrix rapporteerde Manizada dat standaardconfiguraties exploitbaar waren op onder meer (samengevat): AlmaLinux 9 en 10, Alpine 3.22 t/m 3.24, Amazon Linux 2023, Arch, CentOS Stream 9 en 10, Debian 12 en 13, Fedora 42 t/m 44, Gentoo, Kali 2026.1, Linux Mint 22.3, NixOS, openSUSE Tumbleweed, Pop!_OS, Rocky Linux 9 en 10 en Ubuntu 22.04.
Voor Ubuntu 24.04 gaf de publicatie aan dat AppArmor de directe route via namespaces blokkeert, maar dat een fallback met aa-exec -p trinity de bereikbaarheid kon herstellen. Bij Ubuntu 26.04 zou de route voor gewone gebruikers in de standaardinstellingen geblokkeerd zijn; door het AppArmor user-namespace gedrag te wijzigen zou exploitatie alsnog mogelijk worden in de geteste opstelling.
Enkele voorbeelden waar de gepubliceerde route juist niet werkt in de testset: Amazon Linux 2, Debian 11, Rocky Linux 8 en Ubuntu 20.04. Daar bleven oudere codepaden volgens de publicatie buiten schot.
Fix en upstream: welke kernelversies zijn gepatcht?
De upstreamfix is uitgebracht in de stable trees op 24 juli. In de publicatie worden de eerste vaste upstream releases genoemd als: Linux 5.15.212, 6.1.178, 6.6.145, 6.12.97, 6.18.40 en 7.1.5.
Belangrijk detail: niet elke branch krijgt verder nog stable backports. De publicatie geeft aan dat de end-of-life reeksen 6.13 t/m 6.17, 6.19 en 7.0 niet meer in aanmerking komen voor upstream stable fixes.
Tegelijk waarschuwt de bron dat je upstreamnummers niet op zichzelf moet vertrouwen. Distributies leveren vaak backports en downstreamwijzigingen; voor de “echte” status is de vendor tracker daarom de veiligste bron.
Wat moet je nu doen? Praktische mitigaties
Als je nog geen gepatchte kernel hebt, is snelheid belangrijk. De publicatie noemt als kernactie: installeer een gepatchte vendor kernel waar die beschikbaar is.
Is Open vSwitch niet nodig, dan kun je als interim-stap proberen toekomstige module-lading te blokkeren. Een voorbeeld uit de publicatie:
echo ‘install openvswitch /bin/false’ > /etc/modprobe.d/ovswrap.conf
Let op: als de module al in het geheugen geladen is, voorkomt dit niet dat die al actief is. Dan moet je de module verwijderen of herstarten.
User namespaces en modulegedrag: extra aandachtspunten
Het uitschakelen van unprivileged user namespaces sluit volgens de beschrijving de route voor een gewone lokale gebruiker. Maar het blokkeert niet per definitie alles, want een aanvaller die al CAP_NET_ADMIN heeft binnen een netwerknamespace die hij onder controle heeft, blijft theoretisch in staat om via andere paden invloed uit te oefenen.
De publicatie spreekt in dat verband over containergerichte routes die mogelijk “theoretisch bereikbaar” zijn, maar niet zijn aangetoond met de vrijgegeven PoC.
Daarnaast is er in het PoC-repository melding van een “emergency BPF guard” voor omgevingen die zowel Open vSwitch als namespaces nodig hebben. Gebruik zo’n guard alleen wanneer je precies weet welke voorwaarden gelden binnen jouw beheer- en kernelcontext.
Relatie met bredere beveiliging: voorkom keten-incidenten
OVSwrap past in een patroon dat we vaker zien: een lokaal probleem dat door gedeelde resources (of door misbruikbare kernelpaden) snel kan escaleren naar volledige systeemcontrole. Daarom blijft het van belang om niet alleen te patchen, maar ook om te kijken naar harde scheidslijnen tussen accounts en workloads.
Als je dit soort risico’s in je processen wil meenemen, helpt het om ook aandacht te hebben voor hoe incidentdata en threat intel gedeeld wordt met de juiste afspraken. Wellicht vind je de SAFE-richtlijnen voor het delen van AI-incidentdata bruikbaar als je securityteams (ook) met AI of geautomatiseerde analyses werken.
En omdat tokens en verkeerde configuraties in allerlei tooling kunnen opduiken, is het daarnaast nuttig om in het achterhoofd te houden hoe snel een klein lek kan uitgroeien. Als je recente voorbeelden zoekt rondom misbruik van exposeerde gegevens, lees dan ook leaked n8n API tokens—niet hetzelfde onderwerp als OVSwrap, maar wel dezelfde les: “toegang die je niet verwacht” wordt het startpunt voor grotere incidenten.
Conclusie
OVSwrap Linux Open vSwitch (CVE-2026-64531) is een serieuze kernelkwetsbaarheid waarbij lokale gebruikers onder specifieke omstandigheden via de Open vSwitch datapath naar root kunnen escaleren. De combinatie van een memory-corruption bug, een wraparound-lengteveld en een openbare PoC met vooraf voorbereide records maakt deze melding urgent.
De beste aanpak blijft: upgrade naar een gepatchte vendor kernel. Als Open vSwitch niet vereist is, blokkeer dan module-lading als noodmaatregel en herstart om reeds geladen modules te verwijderen. Houd daarnaast unprivileged user namespaces en modulegedrag scherp in de gaten in gedeelde omgevingen—daar kan één account al snel het begin zijn van een hele-server aanval.
Bron: https://thehackernews.com/2026/08/new-ovswrap-linux-kernel-flaw-lets.html
