Er is een nieuwe Linux-kwetsbaarheid opgedoken die zowel beheerders als virtualisatie-teams direct raakt. De fout, Vghost Linux-kernel (CVE-2026-74580), zit in het vhost-subsystem van de kernel. Daardoor kan een lokale gebruiker kernelgeheugen lezen en schrijven, met als eindpunt rootrechten op vrijwel een hele reeks kernelversies. In een specifieke virtualisatie-opzet kan een onbevoegde gast bovendien invloed uitoefenen op de host via QEMU.
Het bijzondere: de aanval is deterministisch. Dat betekent dat er geen “geluk” of complexe timing nodig is om tot de kern van het probleem te komen.
Wat is Vghost Linux-kernel precies?
Het vhost-onderdeel versnelt netwerk- en andere input/outputpaden voor virtuele machines en containers. Lokale toegang tot dat systeem loopt doorgaans via een device node, vaak /dev/vhost-net of /dev/vhost-vsock.
Volgens de bevindingen van Tencent Zhuque Lab kan een unprivileged gebruiker via die route op betrouwbare wijze naar willekeurige kerneladressen lezen en schrijven. Vervolgens kan de aanvaller de bescherming KASLR omzeilen en escaleren naar root.
Wie is er getroffen en welke kernelversies?
De kwetsbaarheid beïnvloedt Linux kernels van 4.11 tot en met 7.2-rc4. In reproduceerbare tests slaagde Tencent erin om de volledige keten van lokale gebruiker → root op vijf distributieomgevingen te bevestigen, waaronder Ubuntu 26.04, RHEL 9.8, Amazon Linux 2023, Microsoft Azure Linux 3.0 en Oracle Linux 10.2.
Opvalt in de testcontext: op Ubuntu bleek de device node standaard beperkt tot de kvm-groep. Daar lag de startpositie dus niet bij elke lokale gebruiker, maar bij iemand die al lid was van die groep. Op de andere geteste images was de node juist breder bereikbaar: wereldleesbaar (mode 0666) waardoor elke lokale gebruiker toegang kon krijgen.
Waarom werkt het zo goed? De kern zit in vhost-cachelogica
De kern van het probleem draait om hoe vhost geheugen-mappingen bijhoudt. Het systeem bewaart een kleine cache met mapping-informatie achter virtuele “ringen” en de gedeelde queues die worden gebruikt voor dataverkeer tussen componenten.
Bij een zogenoemde “cache hit” behandelt vhost dat als bewijs dat een regio al gecontroleerd is. Die cache wordt wel gewist bij bepaalde gebeurtenissen (zoals het updaten of ongeldig verklaren van een mapping, of bij een queue-reset), maar niet bij specifieke commando’s die de ringadressen of ringgrootte kunnen wijzigen terwijl de queue actief blijft.
Wanneer daarna de vertaling van adressen op basis van de oude mapping doorgaat, voert de kernel vervolgens een kopieeroperatie uit zonder de nodige bounds-check. Het gevolg: een lezing of schrijfactie kan buiten het juiste bereik landen, en dat geeft de aanvaller de mogelijkheid om kernelgeheugen te lezen en te schrijven.
Waarom bestond dit zo lang?
Uit de analyse volgt dat de bug ongeveer negen jaar in de codebasis kon blijven. Er waren in die periode twee “op zichzelf redelijke” aanpassingen nodig om het gatenpatroon te creëren. Een wijziging rond Linux 4.11 introduceerde de cache en de shortcut ervan, en later (rond Linux 5.9) werd het adres-checkproces verplaatst naar een later stadium. Daardoor werd het moment waarop vhost had kunnen ingrijpen te laat.
Kan een gast de host beïnvloeden?
Naast lokale root-toegang is er ook een tweede, smallere aanvalslijn. Die draait om een virtuele machine die een virtio-apparaat gebruikt in combinatie met een virtual IOMMU, waarbij iommu_platform is ingeschakeld. In zo’n setup kan vhost draaien in een device-IOTLB-modus.
In die configuratie kan een onbevoegde gast de kwetsbaarheid triggeren en de hostkernel laten schrijven naar een out-of-bounds locatie richting het QEMU-proces. Van daaruit kan een gast bijvoorbeeld een function pointer in QEMU overschrijven om de uitvoering te sturen, of het proces destabiliseren en doen crashen.
Dit is dus geen “standaard” effect voor elke virtuele omgeving, maar het benadrukt wel dat juiste hardening en patching extra belangrijk zijn voor infrastructuur die meerdere trust-zones combineert.
Beoordeling: hoe ernstig is Vghost Linux-kernel?
De kwetsbaarheid wordt door diverse beoordelaars als high geclassificeerd (niet “critical”). De exacte score verschilt. De kernel.org CVE-teamscore komt uit op 8.8 en geeft bovendien aan dat de scope is gewijzigd, omdat de gast-to-host beïnvloeding een grens overschrijdt tussen gast en host via memory in het QEMU-proces.
Andere partijen geven scores rond de 7-range. Zo noteert Red Hat bijvoorbeeld 7.3 en Amazon/Oracle zitten ook in dezelfde bandbreedte. De kernboodschap blijft: de impact is aanzienlijk, en het risico groeit zodra toegang tot de vhost-device nodes niet strikt is ingericht.
Is er al misbruik gezien?
Op basis van de beschikbare info is er geen publieke aanwijzing dat de kwetsbaarheid al actief is uitgebuit. Tencent heeft wel werkende demonstraties gepubliceerd voor beide aanvalspaden, na het vinden van de fout.
Patchadvies: zo verklein je het risico
De fix is beschikbaar in een kernelcommit met referentie de845981da67. In de kern komt de maatregel neer op het wissen van de cache wanneer de ring opnieuw wordt geconfigureerd. Daardoor faalt de logica die de stale vertaling mogelijk maakte.
Het concrete advies: installeer een kernel die deze wijziging bevat en herstart zodat je volledig met de gepatchte code draait. Upstream stable-releases zijn door leveranciers doorgaans ook teruggeporteerd, soms zonder versienummerwijziging, afhankelijk van het backportbeleid.
Wat als je nog niet kunt patchen?
Er is geen universele “interim workaround” die het gast-naar-host escape-pad afdekt. Voor de lokale root-keten kun je echter wel proactief beperken:
- Beperk toegang tot /dev/vhost-net en /dev/vhost-vsock.
- Verwijder world access (zoals mode 0666) als dat aanwezig is.
- Laat alleen een vertrouwde groep of service deze device nodes gebruiken.
- Behandel lidmaatschap van die groep als een geprivilegieerde status zolang de kwetsbare kernel actief is.
Met andere woorden: als je de toegang tot de startpunten van de aanval sluit, daalt de kans dat een lokale gebruiker de keten kan opstarten.
Machine-assisted onderzoek: niet hetzelfde als AI-aanval
De kwetsbaarheid is gevonden met assistentie van Corvus AI, een multi-agent systeem dat Tencent ontwikkelde voor kernel kwetsbaarheidsonderzoek. Dat is relevant nuanceerwerk: dit gaat om machine-assisted detectie in een researchproces, niet om een AI-tool die zelfstandig aanvallen runt.
Tegelijk laat dit zien dat het tempo van kwetsbaarheidsanalyse stijgt. Het is verstandig om je patch- en hardeningproces te beoordelen, zeker voor omgevingen waarin virtualization features een rol spelen.
Versterk je virtualisatie-hygiëne
Vghost Linux-kernel legt pijnlijk bloot hoe belangrijk correct geconfigureerde apparaattoegang en trust boundaries zijn. Het is niet alleen een “patch en klaar”-punt: als je te brede permissies geeft aan device nodes, wordt een lokaal risico sneller een systeemrisico.
Als je kijkt naar bredere beveiligingscontext rond identity en verdediging, kan het ook helpen om je aanpak te spiegelen aan principes zoals Zero Trust en Identity. Voor patchmanagement en detectieprocessen zijn daarnaast tools en methodes uit andere security updates handig om je werkwijze te blijven aanscherpen.
Conclusie
Vghost Linux-kernel (CVE-2026-74580) is een serieuze kwetsbaarheid in het vhost-subsystem. Het geeft lokale gebruikers betrouwbare kernel-lees/schrijfmogelijkheden en kan leiden tot root. In een specifieke virtuele configuratie kan een gast bovendien de hostomgeving beïnvloeden via QEMU.
De beste stap is: patch nu met de kernel die de cache-wislogica toepast (de commit de845981da67) en herstart. Tot dat moment: minimaliseer de toegang tot /dev/vhost-net en /dev/vhost-vsock en maak membership in de relevante groep zichtbaar als een vorm van privilege.
Bron: https://thehackernews.com/2026/10/ai-found-linux-kernel-flaw-gives-local.html
