v4bel/januscapeExploit d'évasion de l'invité vers l'hôte KVM/x86 (CVE-2026-53359) exploitant un use-after-free dans l'émulation de la MMU fantôme. Inclut un PoC pour déclencher un kernel panic de l'hôte et une évasion complète sur les architectures Intel/AMD.
Ce document décrit la vulnérabilité Januscape (CVE-2026-53359) découverte et signalée par Hyunwoo Kim (@v4bel). Il s'agit d'une vulnérabilité d'échappement KVM qui permet à un invité de s'échapper vers l'hôte dans un environnement KVM/x86. À la connaissance du public, il s'agit de la première recherche d'exploit invité-vers-hôte déclenchable à la fois sur Intel et AMD, plutôt que limitée à une seule architecture.
Januscape est une vulnérabilité use-after-free dans l'émulation shadow MMU de KVM/x86. Elle peut déclencher le bogue avec uniquement des actions côté invité pour corrompre la page shadow du noyau hôte, et elle peut menacer l'isolation invité-hôte des hôtes KVM/x86 qui acceptent des invités non fiables et exposent la virtualisation imbriquée, en particulier les clouds publics x86 multi-locataires (GCP, AWS, etc.).
En fait, Januscape a été utilisé avec succès en tant qu'exploit 0-day dans Google kvmCTF.
Pour les informations techniques détaillées, voir ici.
[!NOTE] Après avoir signalé cette vulnérabilité à [email protected], l'embargo convenu a pris fin, donc l'exploit est publié sur oss-security et ce document Januscape est publié. Pour le calendrier de divulgation, consultez le document technique détaillé.
L'exécution du PoC à l'intérieur d'une VM invitée peut déclencher un panique du noyau hôte. Un exploit d'échappement complet fonctionnant dans un environnement contrôlé existe également, mais il n'est pas publié pour le moment et sa publication est prévue dans un avenir très lointain.
Sur des distributions comme RHEL, /dev/kvm est accessible en écriture par tous (0666), donc un utilisateur non privilégié pourrait également transformer cette vulnérabilité en une LPE fiable vers root. Cela dit, ce serait comme payer de l'or pour des déchets, donc je ne me donnerai pas la peine de le couvrir.
# sudo apt-get install -y build-essential linux-headers-$(uname -r)
# make
[Intel]
# sudo rmmod kvm_intel; sudo insmod poc.ko
[AMD]
# sudo rmmod kvm_amd; sudo insmod poc.ko amd=1
[*] poc step 4/4: race live -- host DoS triggering
...
kernel BUG at arch/x86/kvm/mmu/mmu.c (pte_list_remove)
Comm: qemu-kvm
Ce PoC vise à fournir des informations précises. Ne l'utilisez pas sur des systèmes que vous n'êtes pas autorisé à tester.
Januscape (CVE-2026-53359) couvre la plage de 2032a93d66fa (2010-08-01) à 81ccda30b4e8 (2026-06-16).
En d'autres termes, cette vulnérabilité est restée dormante pendant environ "16 ans".
Il y a deux impacts au total :
/dev/kvm est accessible en écriture par tous (0666), donc un utilisateur non privilégié peut également utiliser cette vulnérabilité comme une LPE fiable pour obtenir root.Si vous exploitez un hôte KVM x86 qui accepte des invités multi-locataires et prend en charge la virtualisation imbriquée, ou si vous utilisez une instance sur un tel hôte, vérifiez que le correctif 81ccda30b4e8 est appliqué au noyau hôte.
Non. La vulnérabilité n'est déclenchée que sur les architectures Intel et AMD. Cela dit, si vous n'avez pas encore corrigé le ITScape (CVE-2026-46316) publié précédemment, vos hôtes arm64 sont également vulnérables, alors appliquez le correctif rapidement.
Non. Contrairement aux vulnérabilités d'échappement QEMU couramment publiées, Januscape se produit dans le KVM intégré au noyau, donc il est déclenché indépendamment de l'émulation de QEMU. De ce fait, il peut également menacer les grands clouds publics qui implémentent et utilisent leur propre pile de virtualisation.
Oui. L'insertion du module nécessite des privilèges de noyau invité. Lorsque vous obtenez une instance sur un cloud public, vous avez généralement root sur votre propre VM, donc cette condition est satisfaite. Dans un scénario sans root invité, il doit être chaîné avec une LPE telle que Dirty Frag.