Een ARM64 KVM kwetsbaarheid in de Linux kernel kan ervoor zorgen dat een virtuele machine (guest) toegang krijgt tot vrijgegeven hostgeheugen. Daarmee kan een guest op een host met nested virtualization mogelijk zelfs ontsnappen uit de eigen sandbox en code op de onderliggende machine uitvoeren.
De fout is geregistreerd als CVE-2026-89775 en is door een securityonderzoeker openbaar gemaakt. Er is (voor zover bekend) geen exploitcode gepubliceerd en er zijn geen aanwijzingen dat de kwetsbaarheid al actief wordt misbruikt.
Wat gaat er mis bij CVE-2026-89775?
De bug zit in het KVM-virtualisatiegedeelte voor ARM64 dat specifiek betrekking heeft op nested virtualization. Nested virtualization maakt het mogelijk dat een guest op zijn beurt weer hypervisor-functionaliteit kan draaien en daarbinnen virtuele machines kan hosten.
Op ARM64 is dit mechanisme niet standaard ingeschakeld. Het gaat om een experimentele boot-time modus die Armv8.4-hardware vereist met de feature FEAT_NV2. Een “gewone” ARM64 KVM-host die die optie niet activeert, valt daarmee in de praktijk buiten het door de onderzoeker geschetste aanvalspad.
Technisch gezien is het probleem gekoppeld aan een geheugenafhandeling in de KVM code: wanneer een guest het geheugen op een bepaalde manier organiseert, kan een berekening uitkomen op nul. Daardoor wordt een stap overgeslagen die hoort om oude entries uit de adrescache te wissen (een TLB-invalidation).
Het gevolg is dat een pagina van hostgeheugen die eerder is vrijgegeven, blijft gemapt en schrijfbaar. De guest kan die pagina vervolgens lezen en schrijven per 64-bit blokken, zonder dat er een hardware-trap terug is naar de host om dit af te vangen.
Welke impact heeft de ARM64 KVM kwetsbaarheid?
Volgens de onderzoeker kan een guest via deze route ontsnappen uit de virtuele omgeving. Concreet betekent dat: de guest breekt uit en kan vervolgens code op de host uitvoeren.
Er is ook een tweede misbruikvariant die vooral relevant wordt in omgevingen waar gebruikers lokaal toegang hebben tot de KVM device. Als een gebruiker /dev/kvm mag openen (dus het device is toegankelijk), kan die gebruiker zelf een guest opzetten en op die manier de kwetsbaarheid inzetten om rootniveau te bereiken. Deze route vereist opnieuw dat nested virtualization aan staat op de host.
De onderzoeker noemt als voorbeeld Red Hat Enterprise Linux, waar /dev/kvm standaard voor alle gebruikers open kan staan. Red Hat meldt dat kernelversie 10 wordt geraakt, terwijl versies 6 tot en met 9 niet zouden zijn getroffen (al blijft het scenario hangen aan de voorwaarde van nested virtualization).
Voorwaarden: waarom niet elke ARM64 host geraakt wordt
De belangrijkste beperking is scope. De aanval werkt alleen op hosts waar nested virtualization effectief is ingeschakeld. Omdat dit op ARM64 doorgaans uit staat (en bovendien experimenteel is en hardware-specifieke vereisten heeft), is de kwetsbaarheid in veel standaarddeployments minder urgent dan vergelijkbare “universele” fouten.
Toch is de praktijk breder dan alleen het idee van “wel/niet aan”. In cloud- en virtualisatieomgevingen kan de configuratie verschillen per tenant, regio, platform of provisioning-methode. Het is dus verstandig om niet blind op “ARM64 in het algemeen” te vertrouwen, maar gericht te controleren of het vereiste pad actief is.
Welke Linux kernelversies zijn gepatcht?
Upstream is de fix opgenomen in meerdere Linux kernels. De Linux kernel is gerepareerd in:
- Linux 6.18.51
- Linux 7.2.5
- Linux 7.3-rc1
Distributies nemen updates op eigen tempo, dus de beschikbaarheid kan verschillen per release. Sommige vendors hebben de status en prioriteit daarom anders ingeschat.
Daarnaast is er in het bericht een nuance genoemd richting de codebasis: de kernellog van de projectkant vermeldt dat het betrokken stuk code aanwezig is vanaf Linux 6.16. Tegelijk geeft de fix-onderbouwing aan dat het “missed invalidation”-gedrag pas vanaf v6.17 echt relevant zou zijn voor de attacker.
Is er een workaround als patchen niet lukt?
Voor hosts die nog niet kunnen worden gepatcht, geeft Red Hat aan dat er geen mitigatie voldoet aan hun criteria als workaround. Als alternatief blijft het vooral zaak om het risico te beperken via configuratie.
Omdat het scenario leunt op nested virtualization, ligt de kern van risicoreductie dus in het controleren en eventueel uitzetten van die functionaliteit waar dit mogelijk is. Zorg er daarbij ook voor dat je weet wie toegang heeft tot KVM devices zoals /dev/kvm.
Hoe groot is het risico en is misbruik al gezien?
De impact wordt door vendors hoog ingeschat. De ernstscores lopen uiteen van 7.8 tot 9.3 op een schaal van 10. Dat verschil wordt onder meer verklaard door de inschatting van exploitmoeilijkheid: hoe lastig het is om de bug in de praktijk betrouwbaar uit te buiten.
Verder wordt het type aanval beschreven als lokaal. Dit betekent dat de kwetsbaarheid doorgaans niet “over het netwerk” te starten is; het gaat om een guest-to-host escape-context.
Ten tijde van de publicatie stond de kwetsbaarheid nog niet in de Amerikaanse CISA-catalogus van exploited vulnerabilities. Ook lag de voorspelde exploitatiekans volgens de aangehaalde inschatting onder 1%.
Cloud-tanents en platformkeuzes: wat betekent dit voor providers?
De publicatie roept de vraag op of cloud-tanents via deze route toegang kunnen krijgen tot machines van een provider. In het bericht wordt echter genoemd dat de grootste aanbieders het benodigde configuratiepad voor ARM niet “standaard” aanbieden.
Amazon Web Services zou nested virtualization alleen leveren voor Intel-gebaseerde instances. Google Cloud zou ARM virtual machines juist uitsluiten van die mogelijkheid. Dat betekent niet dat het risico overal nul is, maar het specifieke aanvalspad blijkt niet breed beschikbaar via de standaard ARM offerings zoals in het bericht aangehaald.
Vergelijkbare KVM-escapes: waarom dit onderwerp blijft terugkomen
De onderzoeker positioneert CVE-2026-89775 als de vierde KVM guest-to-host escape die hij in hetzelfde jaar openbaar maakte. Eerder waren er vergelijkbare escapes in de x86-variant (met namen die in het bericht worden genoemd) en er was ook een ARM64 escape (ITScape) die eerder als eerste openbaar gedemonstreerde ARM64 escape werd beschreven.
Voor organisaties is dat een signaal: virtualisatie en sandboxing zijn krachtig, maar fouten in de “randzone” tussen guest en host kunnen juist daar hard binnenkomen. Daarom verdienen updates en configuratiecontroles extra aandacht wanneer je met nested virtualization of intensief gebruikte KVM-omgevingen werkt.
Wat kun je nu doen?
Als je Linux op ARM64 gebruikt met KVM, volg dan deze praktische stappen:
- Check je kernelversie en upgrade naar ten minste één van de gepatchte releases (zoals 6.18.51 of 7.2.5).
- Controleer nested virtualization: staat FEAT_NV2/het boot-time pad aan op de host?
- Beperk toegang tot /dev/kvm waar dat kan, zeker in omgevingen met meerdere gebruikers.
- Valideer cloud/configuratie als je on-demand of maatwerk-images draait: “ARM64” zegt niet genoeg over nested virtualization.
Wil je breder kijken naar hoe SOC-teams en securitymonitoring omgaan met exploit- en aanvalspatronen rond infrastructuur? Lees dan ook eens SOC zicht op DORA-aanvallen: kan dat echt? voor inzicht in detectie en context in plaats van alleen indicatoren.
Conclusie
De ARM64 KVM kwetsbaarheid (CVE-2026-89775) laat zien hoe een specifieke fout in nested virtualization kan leiden tot hostgeheugen dat ten onrechte beschikbaar en schrijfbaar blijft voor een guest. De fix staat al in meerdere Linux kernels, maar de praktische urgentie hangt sterk af van je configuratie: op ARM64 is nested virtualization niet standaard en valt veel “default” gebruik buiten het gerapporteerde aanvalspad.
Desondanks is het verstandig om gericht te updaten en vooral te controleren of de risicovoorwaarden in jouw omgeving aanwezig zijn. Daarmee voorkom je dat een virtuele machine alsnog de deur kan vinden naar de host.
Bron: https://thehackernews.com/2026/09/new-linux-kernel-flaw-gives-arm64-kvm.html
