ITScape : évasion invité-vers-hôte dans KVM/arm64

Résumé

Ce document décrit la vulnérabilité ITScape (CVE-2026-46316) signalée et corrigée par Hyunwoo Kim (@v4bel). Il s'agit d'une vulnérabilité d'évasion KVM qui permet à un invité de s'échapper vers l'hôte dans un environnement KVM/arm64 et d'exécuter des commandes sur l'hôte avec les privilèges du noyau (root). À la connaissance du public, c'est la première recherche d'exploitation d'évasion invité-vers-hôte ciblant KVM/arm64.

ITScape exploite une condition de course dans l'émulation vGIC-ITS (Interrupt Translation Service) de KVM/arm64. Il déclenche le bug avec uniquement des actions côté invité pour s'échapper vers l'hôte, et il peut menacer l'isolation invité-hôte des hôtes KVM/arm64 qui acceptent des invités non fiables, en particulier les clouds publics arm64 multi-locataires.

Contrairement aux évasions QEMU couramment publiées, le bug se trouve dans le KVM en noyau plutôt que dans l'espace utilisateur de QEMU, il fonctionne donc indépendamment de l'émulation de QEMU, et il peut exécuter des commandes sur l'hôte avec le privilège du noyau hôte plutôt qu'avec le privilège d'un processus utilisateur (tel que QEMU).

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, c'est pourquoi ce document ITScape est maintenant publié. Pour le calendrier de divulgation, voir le document de détail technique.

Structure du PoC

Pour des tests sûrs, il est recommandé d'exécuter le PoC sous QEMU TCG. (Le déclenchement de la vulnérabilité n'a rien à voir avec QEMU.) Lorsqu'il est exécuté sous QEMU TCG, le PoC a la structure suivante.

QEMU TCG: emulates an arm64 CPU (including EL2) so an arm64 kernel runs as the KVM host
   └─ arm64 Host Kernel: the KVM host and the escape target
        └─ poc: opens the HOST's /dev/kvm and creates one guest VM "G" (uid=1000)
             └─ 1. G's guest code (run by poc via KVM_RUN) performs GIC/ITS MMIO
                2. traps into the HOST's in-kernel KVM -> double-put -> HOST kernel code-exec

Ce PoC n'est pas un exploit entièrement armé qui s'exécute immédiatement dans un environnement cloud arm64, mais un code de démonstration qui reproduit la vulnérabilité et la chaîne d'exploitation complète sur la base d'un kvm selftest. Un attaquant qui connaît l'implémentation de la pile de virtualisation du cloud cible ne devrait pas trouver difficile la transition vers l'armement, mais elle implique de porter la construction directe côté hôte du selftest vers un chemin réel piloté par l'invité et d'ajuster les adresses, le gadget, les offsets, le timing de la course, etc., en fonction de la version et de la configuration du noyau cible. Un exploit réel armé existe mais n'est pas publié.

Utilisation du PoC

1. Le PoC est construit sur la base du kvm selftest dans les sources du noyau Linux. Téléchargez les sources du noyau v7.1-rc6, la version juste avant que la vulnérabilité ne soit corrigée, puis compilez le PoC avec le script de compilation. Compilez ensuite l'image du noyau avec le kconfig fourni.

# ./build.sh <linux>/tools/testing/selftests/kvm

2. Placez le PoC compilé dans un initramfs approprié, puis exécutez qemu à l'aide du script QEMU fourni.

# ./qemu.sh <kernel-image> <initramfs>

3. Une fois que QEMU TCG a démarré, exécutez poc. En cas d'exploitation réussie, il s'échappe de l'invité et crée le fichier /ITScape sur l'hôte.

# ./poc
...
[+] /ITScape created by the host kernel (owner uid=0). verify:  ls -la /ITScape
# ls -la /ITScape
-rw-r--r--    1 0        0                0 Jun  9 00:02 /ITScape

Ce PoC est destiné à fournir des informations précises. Ne l'utilisez pas sur des systèmes que vous n'êtes pas autorisé à tester.

Versions concernées

ITScape (CVE-2026-46316) couvre la plage allant de 8201d1028caa (2024-04-25) à 13031fb6b835 (2026-06-05).

FAQ

Devrais-je m'inquiéter ?

Si vous exploitez un hôte KVM arm64 qui accepte des invités multi-locataires, ou si vous utilisez une instance sur un tel hôte, vérifiez que le correctif 13031fb6b835 est appliqué au noyau de l'hôte (les opérateurs directement, les locataires via leur fournisseur). De plus, comme il s'agit d'une nouvelle classe de vulnérabilités, des variantes et des vulnérabilités de suivi sont attendues, alors restez vigilant. Cela dit, vous devrez déterminer si une vulnérabilité de suivi peut réellement être déclenchée par les seules actions de l'invité sans action côté hôte, et si elle est effectivement exploitable.

Cela affecte-t-il x86 ou d'autres architectures ?

Non. La vulnérabilité se trouve dans arch/arm64/kvm/vgic/. Si vous n'êtes pas sur un hôte KVM arm64, vous n'avez pas à vous soucier de cette vulnérabilité.

Ai-je besoin des droits root dans la VM invitée ?

Oui. Piloter les MMIO GIC/ITS nécessite les privilèges du noyau invité (EL1). Lorsque vous obtenez une instance sur un cloud public, vous avez généralement les droits root sur votre propre VM, donc cette condition est satisfaite. Dans un scénario sans root dans l'invité, elle doit être chaînée avec une LPE telle que Dirty Frag.