Une nouvelle vulnérabilité, baptisée Zapscape, vise KVM et plus précisément la gestion de la mémoire shadow-MMU côté noyau Linux. Dans un contexte de virtualisation imbriquée, un attaquant disposant de privilèges élevés au sein d’un invité de niveau 1 (L1) pourrait, dans certaines configurations, contourner l’isolation KVM et exécuter du code sur l’hôte. La faille est suivie sous la référence CVE-2026-64561, et un correctif a déjà été fusionné en amont.
La particularité de Zapscape réside dans l’enchaînement d’étapes déclenchées pendant la gestion des défauts de pages, menant à une situation de type use-after-free. Autrement dit, KVM peut continuer à utiliser des structures mémoire considérées comme libérées ou invalidées, ce qui ouvre la porte à des effets allant jusqu’à la compromission de l’hôte, sous des conditions précises.
Pourquoi la Zapscape faille KVM est préoccupante
Le scénario décrit par le chercheur à l’origine de la découverte concerne un assaillant disposant de privilèges noyau à l’intérieur d’une machine virtuelle L1. L’impact n’est pas « automatique » : il dépend du fait que la virtualisation imbriquée soit exposée à des invités non fiables, et de certaines exigences spécifiques à l’architecture.
Si ces conditions sont réunies, la vulnérabilité peut permettre à l’attaquant d’atteindre un niveau d’exécution sur l’hôte, avec des privilèges de type kernel ou root sur la machine hôte. Le risque se concentre donc sur les environnements où KVM exécute des invités capables de provoquer des chemins de code particuliers dans la couche noyau.
Fonctionnement : shadow-MMU et ordre de vérification
Zapscape se situe dans la tenue des registres et métadonnées de shadow-MMU de KVM/x86. Cette composante gère les tables de pages shadow utilisées pour traduire la mémoire des invités imbriqués.
La cause racine décrite correspond à une erreur d’ordre de vérification (une logique de contrôle évaluée trop tôt) liée à la détection d’un root « périmé » dans le suivi interne. Lors du traitement d’un défaut de page déclenché par le guest, KVM peut réaffecter (reclaim) des pages MMU et invalider le root shadow-MMU en cours d’utilisation par le chemin de traitement.
Le problème apparaît ensuite parce que le chemin en question ne relance pas la vérification du root après cette invalidation. KVM peut ainsi poursuivre sous la racine devenue invalide, puis créer des pages shadow enfants à partir de cet état incohérent.
Du use-after-free à des effets exploitables
Dans la description technique rendue publique, le chercheur explique que KVM vérifie si le root courant est « stale » avant de rendre davantage de pages MMU disponibles. Or, pendant le reclaim, ce root peut devenir invalide, mais le traitement continue et installe des structures enfants sous cette même racine.
Les conséquences vont plus loin : ces pages sont placées dans la liste active des pages MMU de KVM. Ensuite, lors du nettoyage, il devient possible que le même lien de liste se retrouve associé à deux listes différentes, puis que la page soit libérée alors que des références « stale » restent présentes. Ce mécanisme donne naissance à un lien pendu et à une écriture post-libération, typique des use-after-free exploitées en pratique.
CVE-2026-64561 : conditions d’exposition et matériel concerné
La vulnérabilité est référencée CVE-2026-64561 et touche KVM/x86. Le correctif upstream a été intégré, mais l’exposition dépend de votre configuration.
Dans les systèmes Intel, il faut notamment que certaines capacités liées à l’exécution des EPT page-walk soient exposées à l’invité L1 (longueurs 4 et 5). Pour AMD, il n’existe pas de condition équivalente citée de la même façon.
En termes de contexte d’exploitation, le rapport public indique aussi que le chercheur a construit une preuve de concept ciblant des environnements AMD en combinaison avec l’invité imbriqué nested SVM/NPT sur Linux (version de test mentionnée : 7.1.3).
À noter : la preuve de concept ne signifie pas que la faille est déjà exploitée en production. Le chercheur précise que son travail n’est pas un « exploit armé » prêt à déclencher immédiatement dans des environnements cloud, car il faudrait notamment adapter le procédé à la configuration du noyau hôte et intégrer les actions L1 dans un module de guest.
Mise à jour : que doivent faire les administrateurs
Le correctif amont a été fusionné, et la recommandation est claire : si votre infrastructure KVM expose la virtualisation imbriquée à des invités non dignes de confiance, vous devez mettre à jour le noyau ou appliquer un paquet fournisseur incluant le backport.
La difficulté pratique vient du fait que l’état des paquets dépend des trackers de chaque éditeur. Autrement dit, un numéro de version identique ne garantit pas que le correctif soit présent : certains fournisseurs publient des correctifs via rétroportage sans « rebaser » sur une version amont plus récente.
Le correctif mentionné a été intégré sous la forme d’une fusion associée à commit 2abd5287f083. Les changements se concentrent sur le déplacement de la vérification root « stale » après l’appel à make_mmu_pages_available(). En cas d’invalidation du root pendant le reclaim, KVM redémarre alors le traitement du défaut de page avec RET_PF_RETRY, plutôt que de continuer à mapper ou à récupérer sous une racine invalidée.
Versions concernées et statut selon les distributions
Les informations publiées indiquent une fenêtre de versions affectées « jusqu’à correction » au sein de la base de suivi des vulnérabilités : Linux 5.9 et versions ultérieures sont listés comme concernés jusqu’aux versions stables corrigées.
La liste des versions stables mentionnées comme corrigées dans le suivi comprend notamment : 6.6.148, 6.12.101, 6.18.42, 7.1.6 et 7.2-rc5.
En complément, le suivi fourni au moment de la publication mentionne un état spécifique dans le tracker Debian (au 6 août 2026). Selon ce même relevé, bullseye, bookworm et trixie étaient listés comme vulnérables via des paquets de noyau associés à leurs dépôts de sécurité, tandis que forky était également indiqué comme vulnérable. Pour sid, la correction était signalée comme disponible pour 7.1.6-1.
Exploitation : preuve de concept et recommandations de test
Le chercheur a publié une preuve de concept qui démontre l’utilisation de la primitive de use-after-free pour construire une chaîne aboutissant à la création d’un fichier nommé /Zapscape sur l’hôte vulnérable.
Pour les tests en conditions contrôlées, il recommande de mener les essais sous QEMU TCG, afin de limiter l’impact. Il précise également que QEMU n’est pas le composant vulnérable : la faille se trouve dans KVM côté noyau, et le déclenchement dépend du chemin interne propre au composant virtualisation.
Calendrier de divulgation
Le déroulé de la divulgation publique illustre la dynamique habituelle de traitement des vulnérabilités noyau. Le chercheur a d’abord signalé le problème à security@kernel.org le 11 juillet 2026. Un patch a ensuite été publié et fusionné le 21 juillet.
La soumission aux listes a eu lieu le 1er août avec une période d’embargo courte (indiquée à cinq jours), puis l’identifiant CVE-2026-64561 a été assigné le 4 août. La divulgation publique a suivi le 6 août.
Conclusion : surveillez l’usage de la virtualisation imbriquée
La Zapscape faille KVM met en évidence un risque réel dans les environnements où la virtualisation imbriquée est exposée à des invités non fiables. Même si l’exécution de code sur l’hôte exige des conditions précises (notamment des privilèges de type noyau côté L1), l’impact potentiel justifie une action immédiate.
Si vous administrez des hôtes KVM avec des scénarios L1 non maîtrisés, vérifiez votre état de patching et appliquez le correctif via votre noyau ou les paquets de l’éditeur. Dans le doute, partez du principe que le correctif doit être présent dans votre distribution, et pas seulement que la version paraît « suffisamment récente ».
Source: https://thehackernews.com/2026/08/new-zapscape-kvm-flaw-could-let.html
