Présentation de Zapscape et comment protéger les hôtes KVM

En bref

Aller directement à la version longue ↓

Description : la vulnérabilité CVE-2026-64561, baptisée « Zapscape » par son découvreur, Hyunwoo Kim (@v4bel), est une faille de type « use-after-free » affectant l’unité de gestion de la mémoire fantôme x86 de KVM sous Linux. Deux chemins de défaut de page valident la racine de la mémoire fantôme avant de récupérer les pages fantômes, et non après ; ainsi, KVM continue à créer des mappages sous une racine que la récupération a déjà invalidée. Il en résulte une échappée complète de l'invité vers l'hôte. Le PoC publié documente un chemin permettant d'exécuter du code en tant que root sur l'hôte, et pas seulement de provoquer une panique qui tue toutes les machines virtuelles co-locataires. Aller à cette section →

Impact potentiel : Le chercheur décrit une chaîne d'exploitation permettant à un utilisateur invité contrôlé par un attaquant d'exécuter du code au niveau du noyau de l'hôte, ce qui constituerait une évasion totale de la machine virtuelle vers son hôte. La même publication décrit deux autres scénarios : un « panic » de l'hôte qui interrompt toutes les charges de travail en cours d'exécution sur la machine affectée, et une autre chaîne d'exploitation permettant une élévation de privilèges en local, qui part d'un compte ordinaire sur l'hôte où /dev/kvm est accessible en écriture par tous. Aller à cette section →

Gravité : Red Hat attribue à cette vulnérabilité le niveau « Important », avec un score de base CVSS 3.1 de 7,0 sous la référence CWE-825. Son exploitation nécessite des privilèges au niveau du noyau invité, une virtualisation imbriquée et une configuration hôte compatible. Dans sa formulation, Red Hat décrit l’impact comme une instabilité et un déni de service dans les environnements virtualisés, ce qui constitue une interprétation nettement plus modérée que celle du chercheur. Aller à cette section →

Qui est concerné : Hôtes exécutant KVM avec la virtualisation imbriquée activée, sur un noyau intégrant la modification introduite par le commit f95eec9bed76 dans Linux 5.9 et ne contient pas encore le correctif fourni par le développeur en amont 2abd5287f083. Les systèmes AMD SVM utilisant des tables de pages imbriquées sont les plus facilement accessibles. Les systèmes Intel nécessitent que les parcours de pages EPT à quatre et cinq niveaux soient exposés à l'invité de premier niveau, ce qui limite cette voie aux processeurs Ice Lake-SP et plus récents. Aller à cette section →

Ce qui a été vérifié : lors de nos tests, la démonstration publique de principe n’a pas permis de provoquer une évasion d’un environnement invité vers l’hôte sur les noyaux construits avec CloudLinux. Elle ne fonctionne pas sur ces derniers sans modification, et les tests de reproduction menés en interne n’ont jusqu’à présent entraîné qu’un plantage de l’environnement invité de premier niveau. Considérez cette évasion comme plausible, mais pas comme une compromission avérée à l’échelle de l’ensemble du parc. Aller à cette section →

Que faire maintenant : commencez par vérifier si un hôte est concerné ou non.

cat /sys/module/kvm_amd/parameters/nested 2>/dev/null
cat /sys/module/kvm_intel/parameters/nested 2>/dev/null

A 1 ou Y Cela signifie que le module KVM chargé autorise la virtualisation imbriquée, ce qui expose l'hôte à une surface d'attaque potentielle. Cela ne prouve pas à lui seul la possibilité d'exploitation, car l'état des correctifs du noyau, les capacités du processeur de l'hôte, le modèle de processeur virtuel exposé au niveau L1, ainsi que la capacité d'un invité non fiable à créer un niveau L2 restent des facteurs déterminants.

L'absence de sortie signifie généralement que le module KVM correspondant n'est pas chargé pour le moment, ce qui n'est pas la même chose que « hors de portée » ; vérifiez donc comment l'hôte est réellement utilisé et si KVM peut être chargé ultérieurement. Lisez le fichier plutôt que de supposer que personne n'a activé l'imbrication, car le KVM en amont a activé le paramètre d'imbrication par défaut pour Intel et AMD depuis Linux 4.20, et une distribution peut modifier ce comportement par défaut dans un sens ou dans l'autre.

Sur les hôtes qui n'ont pas besoin de virtualisation imbriquée, désactivez-la, car cela supprime la condition préalable dont dépend toute la chaîne. Vérifiez /dev/kvm les autorisations, dans le cadre d'une mesure de renforcement de la sécurité distincte, tant que vous y êtes.

KernelCare corrige cette faille dans le noyau en cours d'exécution sans redémarrage ni redémarrage de la machine virtuelle. Les premiers correctifs sans redémarrage sont désormais disponibles : Debian 13 est dans le dépôt « main », et Ubuntu 24.04, Ubuntu 24.04 pour AWS, Ubuntu 22.04 pour AWS (noyaux 6.8) ainsi que Proxmox VE 8 disposent de versions dans le dépôt « test » qui devraient être promues vers le dépôt « main ». Les autres familles sont encore en cours de compilation et de révision ; leur disponibilité variera selon le noyau et le dépôt à mesure que la validation s'achèvera. Appliquez un noyau corrigé par le fournisseur s'il en existe déjà un pour votre plateforme.

Deux descriptions de Zapscape circulent actuellement, et elles sont très différentes l'une de l'autre. Le chercheur décrit une chaîne d'événements aboutissant à l'exécution de code du noyau hôte depuis l'intérieur d'un invité. Red Hat évoque quant à lui une instabilité dans les environnements virtualisés. Les deux font référence au même commit.

La réponse honnête se situe entre les deux, et les détails ci-dessous expliquent pourquoi. Ce qui a été reproduit en interne est plus limité que ne le laisse entendre la divulgation. La démonstration publique de principe peut provoquer le plantage de l'invité L1 contrôlé par l'attaquant dans certains environnements, tandis que le chercheur documente une voie, dépendante de la configuration, permettant de parvenir à l'exécution de code sur l'hôte. Il convient de souligner clairement cet écart, et aucune de ces deux interprétations ne justifie de laisser une faille dans la virtualisation sans correctif.

La virtualisation imbriquée permet à une machine virtuelle d'exécuter à son tour des machines virtuelles. Un client du cloud peut l'utiliser pour exécuter un hyperviseur, tester des logiciels d'infrastructure, exploiter un environnement d'intégration continue (CI) ou activer des fonctionnalités Windows qui dépendent d'Hyper-V.

On obtient ainsi une structure à trois niveaux :

• L0 est l'hôte physique
• L1 est l'instance invitée contrôlée par l'attaquant
• L2 est une machine virtuelle créée au sein de L1

Zapscape exploite les failles de gestion de la mémoire que L0 commet lorsqu’il traite les activités provenant de L2. L’attaquant commence par obtenir les privilèges root au sein de L1, puis crée l’invité imbriqué nécessaire pour exploiter la voie KVM vulnérable.

Il n'est pas rare d'obtenir des droits root au sein d'une machine virtuelle dans le cloud. Les clients gèrent généralement leurs propres systèmes d'exploitation invités, et la barrière de sécurité est censée empêcher cet accès d'atteindre l'hyperviseur. Zapscape cible cette barrière elle-même.

Le KVM utilise des tables de pages fantômes pour traduire les accès à la mémoire de l'invité en mappages de l'hôte, et libère ces structures dès qu'il atteint son quota de pages MMU actives.

Les voies de rupture vulnérables, direct_page_fault() et FNAME(page_fault)(), intitulé is_page_fault_stale() avant make_mmu_pages_available().

C'est cet ordre qui pose problème.

Rénovation intérieure make_mmu_pages_available() peut supprimer la racine actuellement utilisée par KVM et la marquer comme non valide. Comme la vérification de la racine obsolète a déjà été effectuée, KVM continue à créer des mappages sous une racine qui n’est plus valide. Les pages fantômes enfants héritent du rôle de leur parent ; elles héritent donc de cet état non valide, et les pages non valides se retrouvent à nouveau dans la liste des pages MMU actives.

C'est la validation invariante f95eec9bed76 ajouté dans Linux 5.9 pour éviter cela. Une fois que cela ne fonctionne plus, un nettoyage récursif ultérieur via mmu_page_zap_pte() fonctionne sans root_count assure la surveillance et intervient sur les ouvrages qui ont déjà été dégagés.

La démonstration de faisabilité déclenche la séquence en basculant les modes mémoire au sein de L1 pour créer des pages fantômes d'alias, tandis que l'activité mémoire provenant de L2 pousse L0 vers une récupération basée sur un quota. Le chercheur exploite ensuite la corruption ainsi provoquée pour exécuter du code du noyau de l'hôte.

Le problème d'ordre remonte en fait à 2008. Il a pris une dimension de sécurité dans Linux 5.9, lorsque l'invariant qu'il enfreint a été introduit. Personne n'a signalé de bug dans la version 5.9. Le noyau a simplement commencé à s'appuyer sur une condition qui n'avait jamais été vérifiée auparavant.

Le chercheur fournit une preuve de concept côté invité et décrit le chemin complet menant à l'exécution de code sur l'hôte. L'exploitabilité dépend toutefois fortement de la configuration. Cette faille cible AMD et a été développée pour une configuration spécifique de Linux 7.1.3 sous QEMU TCG plutôt que sur du matériel de production ; pour atteindre un véritable hôte, il faudrait donc réécrire les actions côté invité et les adapter à la configuration du noyau cible.

Nos tests n'ont pas permis de reproduire la fuite complète sur aucun noyau compilé avec CloudLinux. L'exploit public ne fonctionne pas sur ces noyaux sans modification, et le résultat observé est un plantage de l'invité L1, ce qui constitue un déni de service pour la propre machine virtuelle de l'attaquant plutôt qu'une compromission de l'hôte.

Enterprise Linux 8 mérite une mention particulière pour tous ceux qui souhaitent le tester par eux-mêmes. La démonstration de concept publique ne provoque absolument rien sur cette version, pas même un plantage ; elle ne peut donc pas servir de référence « avant-après » pour cette famille de systèmes. Il convient de valider les noyaux EL8 à l'aide d'une suite de tests KVM générale, plutôt que de tirer des conclusions hâtives en se basant uniquement sur l'absence de problème.

Rien de tout cela ne prouve que les noyaux concernés sont sûrs. Cela signifie que la vulnérabilité doit être décrite avec précision. Zapscape présente un chemin d'échappement crédible de l'espace invité vers l'espace hôte, et l'exploit public ne constitue pas actuellement un moyen d'échappement universel pour tous les noyaux contenant le code vulnérable.

Le chemin d'exécution vulnérable existe depuis la modification apportée à Linux 5.9 dans le commit f95eec9bed76, daté du 8 juillet 2020, via des noyaux qui n'ont pas reçu de correctif 2abd5287f083, qui s'est posé en amont le 21 juillet 2026.

L'accessibilité nécessite en outre :

• KVM en service
• La virtualisation imbriquée doit être activée
• Contrôle au niveau du noyau au sein de l'invité L1
• Fonctionnalités du processeur hôte et du processeur virtuel compatibles avec l'attaque

Sur les serveurs AMD utilisant SVM et des tables de pages imbriquées, cette divulgation n'identifie aucune condition préalable supplémentaire liée aux fonctionnalités du processeur, au-delà des principales exigences déjà énumérées. Les systèmes Intel ne sont concernés que lorsque les longueurs de parcours de pages EPT à quatre et cinq niveaux sont exposées à la cache L1, ce qui correspond généralement aux processeurs Ice Lake-SP et plus récents dotés de ces capacités.

Familles de plateformes concernées ou potentiellement concernées identifiées au cours de notre analyse :

• Enterprise Linux 10, AlmaLinux 10 et CloudLinux 10, pour lesquels le portage de CentOS Stream 10 est encore à l'état de projet
• Les anciens noyaux Enterprise Linux 8 et 9 qui ne contiennent pas le correctif du fournisseur, y compris les variantes dérivées d'EL8
• Debian 11, 12 et 13
• Ubuntu 22.04 et 24.04
• Oracle UEK7
• Proxmox VE 7 et VE 8

Déjà corrigé ou hors du champ d'application :

• Les noyaux RHEL 8 provenant de 4.18.0-553.147.1.el8_10 et suivantes, expédiées le 23 juillet 2026
• Les noyaux RHEL 9 provenant de 5.14.0-687.30.1.el9_8 à partir de cette date, expédié le 22 juillet 2026
• RHEL 6 et RHEL 7, y compris kernel-rt, qui sont antérieures à la modification apportée à Linux 5.9 et qui a rendu cette faille critique pour la sécurité
• Tout hôte qui n'exécute pas KVM, ou qui l'exécute avec la virtualisation imbriquée désactivée

Les entrées concernant RHEL comportent toutefois une nuance. Red Hat a publié cette correction discrètement, en la regroupant avec d’autres correctifs de vulnérabilités, et sa page CVE publique a continué à répertorier RHEL 8 et RHEL 9 comme étant affectés après la publication de ces errata. Le journal des modifications constitue une source d’information plus fiable, et il arrive que le statut d’une page change en l’espace de quelques heures ; il est donc recommandé de vérifier à nouveau les données actuelles de Red Hat avant de confirmer à un client ou à un auditeur qu’un système est affecté.

La même prudence s'impose de manière plus générale. Les noyaux des éditeurs intègrent constamment des modifications ponctuelles, de sorte que le numéro de version en amont ne permet pas à lui seul de déterminer le niveau de vulnérabilité. Vérifiez l'avis de sécurité et l'état du correctif pour le noyau exact en cours d'exécution.

Comment atténuer les effets de Zapscape

Toutes les conditions préalables à ce bug peuvent être supprimées. Ces trois mesures sont des solutions temporaires et ne remplacent pas la correction définitive.

1. Désactivez la virtualisation imbriquée. C'est l'option la plus directe, car cette chaîne nécessite que L1 crée et gère sa propre machine virtuelle.

# /etc/modprobe.d/99-zapscape.conf
options kvm_amd nested=0
options kvm_intel nested=0

Le paramètre du module est lu au moment du chargement ; son application implique donc d'arrêter toutes les machines virtuelles en cours d'exécution et de recharger kvm_amd ou kvm_intel. Sur un serveur de production, cela implique un arrêt ou un redémarrage, plutôt qu'une modification en direct.

Si la flotte utilise des machines virtuelles classiques à un seul niveau, appliquez la mise à jour et passez à autre chose, car aucune partie de cette charge de travail ne nécessite de virtualisation imbriquée. Si l'hôte propose délibérément cette fonctionnalité (par exemple pour des locataires d'hyperviseurs imbriqués, des systèmes d'intégration continue qui démarrent des machines virtuelles, des environnements de développement et de test virtualisés, ou des machines invitées Windows utilisant VBS ou Hyper-V), laissez-la activée et concentrez-vous plutôt sur l'application des correctifs. Évaluez l'impact sur la charge de travail avant d'intervenir sur un hôte que vous n'avez pas configuré vous-même.

2. Restreindre l'accès à /dev/kvm. Cela ne résout en rien le problème d'une attaque provenant d'un invité existant. Cela bloque simplement la voie distincte par laquelle un utilisateur local ordinaire de l'hôte peut accéder directement à KVM.

ls -l /dev/kvm

Si l'appareil affiche le mode 0666, le sécuriser et autoriser l'accès aux utilisateurs légitimes via le kvm groupe. Effectuez cette modification dans une règle udev plutôt qu’avec un simple chmod, car udev réinitialise ce mode au prochain démarrage ou lors du prochain événement lié au périphérique.

3. Vérifier l'exposition à l'EPT à cinq niveaux sur Intel. Cela ne s'applique que lorsque les deux capacités EPT atteignent le niveau L1.

grep -w ept_5level /proc/cpuinfo

L'absence de sortie signifie que l'hôte ne dispose pas de la fonctionnalité EPT à cinq niveaux requise par le chemin Intel décrit. Si l'indicateur est présent, la question suivante est de savoir si les EPT à quatre et à cinq niveaux parviennent effectivement jusqu'à l'invité L1 non fiable, puisque /proc/cpuinfo décrit le processeur hôte plutôt que ce que transmet le modèle de processeur virtuel. Lorsque la virtualisation imbriquée doit rester activée, évitez les modèles de processeur qui exposent l'EPT à cinq niveaux à des invités non fiables. Sur les systèmes Intel plus récents, la désactivation de la virtualisation imbriquée reste la mesure temporaire la plus fiable.

Une fois la protection mise en place, supprimez la configuration temporaire à l'aide de la commande suivante : sudo rm /etc/modprobe.d/99-zapscape.conf et recharger le module lors de la prochaine fenêtre de maintenance.

La solution

La correction en amont a été validée 2abd5287f083, « KVM : x86 : Vérification de la présence d'une racine non valide ou obsolète après la mise à disposition des pages MMU. »

La modification est mineure. Elle déplace la vérification de la racine obsolète après make_mmu_pages_available() dans les deux chemins de défaillance concernés, sur une douzaine de lignes modifiées à travers arch/x86/kvm/mmu/mmu.c et arch/x86/kvm/mmu/paging_tmpl.h. KVM procède désormais à toute opération de récupération de mémoire avant de vérifier que la racine est toujours valide avant de poursuivre ; cela empêche l'hyperviseur de créer des mappages actifs sous une racine que la récupération de mémoire a déjà invalidée.

Pas de nouvelle structure de données, pas d'état persistant à suivre. C'est ce qui le rend adapté à l'application de correctifs sans redémarrage, même si le portage lui-même dépend de l'écart entre les chemins de gestion des erreurs du noyau de chaque fournisseur et ceux de la branche principale.

État et déploiement des correctifs KernelCare

Au 11 août 2026, les premières versions sont disponibles :

Debian 13 : dépôt « main »
Ubuntu 24.04 Noble, Ubuntu 24.04 Noble pour AWS, Ubuntu 22.04 Jammy pour AWS, les noyaux 6.8 et Proxmox VE 8 se trouvent dans le dépôt « test »

Les versions de test devaient être intégrées au flux principal le jour même ; vérifiez donc l'état du flux correspondant à votre noyau plutôt que de partir du principe qu'elles sont encore réservées aux tests.

Situation familiale actuelle :

Tous les noyaux Enterprise Linux 9 font l'objet de correctifs en cours d'examen, à l'exception des noyaux les plus anciens de la série 70, qui nécessitent une adaptation et ont été reportés dans le cadre d'un travail distinct.

• Les correctifs pour Ubuntu 24.04 sont prêts et en cours d'examen
• Les correctifs pour Debian 12 sont en cours d'examen et en attente de validation matérielle
• Des correctifs pour Enterprise Linux 8 et Ubuntu 22.04 ont été préparés, mais leur validation est toujours en cours.
• Enterprise Linux 10 est en attente

C'est le matériel de test d'AMD, et non la complexité des correctifs, qui a constitué le facteur limitant pour plusieurs familles de processeurs. La disponibilité variera selon les noyaux jusqu'à la fin des tests et la finalisation du déploiement.

Si vous souhaitez effectuer la mise à jour alors qu'un correctif est encore en phase de test :

kcarectl --update --prefix test

Une fois déployé sur le flux de production, le correctif est appliqué lors de la prochaine exécution planifiée, ou à la demande :

kcarectl --update

Vérifiez ensuite ce qui est réellement chargé sur le noyau en cours d'exécution :

kcarectl --patch-info | grep 'CVE-2026-64561'

L'horodatage de la compilation constitue le deuxième critère de vérification :

kcarectl --info | grep kpatch-build-time

Une version datée du 6 août 2026 ou postérieure constitue un indicateur utile, mais ne garantit pas que ce CVE spécifique soit pris en charge par ce noyau. Si les informations relatives au correctif ne mentionnent pas encore le CVE, vérifiez auprès du service client que ce noyau précis est bien pris en charge, plutôt que de vous fier uniquement à la date. Dans tous les cas, effectuez cette vérification avant de supprimer une mesure d'atténuation temporaire, et non après.

Découvrez comment KernelCare corrige les failles critiques du noyau sans redémarrage →

Chronologie

Références

• Hyunwoo Kim (@v4bel), signalement de Zapscape à oss-security
• Documentation technique et démonstration de faisabilité de Zapscape, zapscape.io
• Correction en amont sous Linux 2abd5287f083, « KVM : x86 : Vérification de la présence d'une racine non valide ou obsolète après la mise à disposition des pages MMU »
• Commit Linux f95eec9bed76, « KVM : x86/mmu : ne pas réintégrer les pages de mémoire (SP) non valides dans la liste des pages actives »
• Avis de sécurité Red Hat et fiche CVE pour CVE-2026-64561
• Demande de fusion n° 3068 pour le backport de CentOS Stream 10, en version brouillon
• Avis de sécurité concernant RHEL, AlmaLinux, CloudLinux, Debian, Ubuntu, Oracle et Proxmox