Évasion de machine virtuelle invitée dans l'hyperviseur Xen (CVE-2026-102703, CVE-2026-102704)

TL;DR

• Deux failles de validation du grant copy de Xen permettent à un invité malveillant de lire et d'écrire la mémoire d'autres domaines, dont Dom0, le domaine de contrôle. Le Xen Project a publié l'avis XSA-523 le 3 novembre 2026.
• Toutes les versions de Xen à partir de 4.6 sont concernées, et Xen 4.5 et les versions antérieures ne le sont pas. Aucune atténuation n'est connue.
• L'avis ne donne aucun score CVSS. Aucune exploitation n'est connue, et aucune des deux CVE ne figure au catalogue Known Exploited Vulnerabilities (KEV) de la Cybersecurity and Infrastructure Security Agency (CISA) au 4 novembre 2026.
• Appliquez les correctifs XSA-523, de 4.17 jusqu'à unstable, à la dernière révision de votre branche stable, ou installez la mise à jour de votre fournisseur de plateforme. Aucune archive publiée de Xen ne les embarque encore. Voir « Comment corriger ? ».

Suis-je concerné ?

Vous êtes exposé lorsque toutes ces conditions sont réunies :

• Vous exécutez l'hyperviseur Xen, version 4.6 ou toute version ultérieure. L'avis indique que toutes les versions à partir de 4.6 sont vulnérables, et que 4.5 et les versions antérieures ne le sont pas.
• Votre déploiement héberge des invités non fiables. Tout invité opérant une grant table peut émettre les opérations de copie vulnérables.
• Vous n'avez pas encore appliqué les correctifs XSA-523. La résolution de l'avis est le jeu de correctifs ; aucune archive publiée de Xen ne l'embarque au 4 novembre 2026.

Les invités sont ici l'attaquant, et non la victime d'un attaquant réseau. Un invité dont la mémoire est lue ou écrite par un voisin malveillant n'en voit aucun indice.

XCP-ng est une plateforme du Xen Project, et sa documentation indique qu'elle est construite autour de l'hyperviseur Xen. Vérifiez ce que votre hôte exécute réellement :

# On the host (dom0): the running Xen version
xl info | grep '^xen_version'

# In a Linux guest: confirms the hypervisor type (prints "Xen" under Xen)
cat /sys/hypervisor/type 2>/dev/null

# In a Linux guest: the hypervisor version the guest was told
cat /sys/hypervisor/version/major 2>/dev/null
cat /sys/hypervisor/version/minor 2>/dev/null

La version indique si un hôte est dans la plage concernée, et toutes les versions depuis 4.6 le sont. Elle ne peut pas indiquer si les correctifs XSA-523 sont appliqués, car aucune version publiée ne les contient. Consultez plutôt l'avis ou le journal des modifications du paquet de votre fournisseur pour XSA-523.

Sur un cloud géré, la vue de l'invité peut être en retard sur l'état de correctif de l'hôte. Demandez à votre fournisseur l'état XSA-523 de l'hôte si vous y exécutez des invités non fiables.

Comment corriger ?

1. Si vous compilez Xen depuis une branche stable, mettez d'abord la branche à jour jusqu'à sa dernière révision, puis appliquez les correctifs XSA-523. Recompilez Xen et redémarrez l'hôte sur l'hyperviseur corrigé. L'avis précise que les correctifs sont préparés pour les branches stables et peuvent ne pas s'appliquer proprement à une archive de version.
2. Si vous exécutez un Xen packagé par un fournisseur de plateforme ou une distribution, appliquez la mise à jour du fournisseur dès sa publication, puis redémarrez l'hôte. Aucune archive publiée de Xen n'embarquait le correctif au 4 novembre 2026.
3. Recréez les invités seulement si votre plan de reprise l'exige. Appliquer le correctif de l'hyperviseur arrête les attaques futures ; il ne vous dit pas si une attaque antérieure a eu lieu.

Aucune solution de contournement par configuration n'existe. L'avis le dit : « There is no known mitigation » (aucune atténuation connue).

Quelle est la cause racine ?

L'hypercall de grant copy permet à un invité de copier des données entre des grant references et des numéros de trames machine. Par souci de performance, le commit d28f42f2703e (« grant-table: defer releasing pages acquired in a grant copy ») a fait mettre en cache par Xen la description validée de l'élément précédent du lot. Ce commit est arrivé dans Xen 4.6.0, en accord avec la plage vulnérable de l'avis.

Un lot d'opérations grant copy agit souvent sur des plages d'adresses adjacentes dans la même page source ou destination. Le cache est réutilisé quand l'élément suivant paraît équivalent. Les deux failles sont de mauvaises conditions pour cette réutilisation, selon la description de l'avis.

CVE-2026-102703 est le contrôle de validité du cache. Dans gnttab_copy_buf_valid(), p est la source ou la destination du nouvel élément, et b est le tampon en cache. has_gref indique si le nouvel élément utilise une grant reference (GREF). Le code vulnérable est xen/common/grant_table.c, lignes 3082 à 3091, dans xen-unstable avant les correctifs :

static bool gnttab_copy_buf_valid(
    const struct gnttab_copy_ptr *p, const struct gnttab_copy_buf *b,
    bool has_gref)
{
    if ( !b->virt )
        return 0;
    if ( has_gref )
        return b->have_grant && p->u.ref == b->ptr.u.ref;
    return p->u.gmfn == b->ptr.u.gmfn;
}

Le champ ->have_grant indique si l'entrée en cache provient d'une grant reference. Le code ne le vérifie que sur le chemin des grant references, avant la comparaison des GREF. Le chemin des trames machine compare p->u.gmfn == b->ptr.u.gmfn sans vérifier que l'entrée en cache était aussi une entrée de trame.

La description du correctif en donne la conséquence : une GREF d'un élément antérieur du lot, probablement invalide, peut être prise pour un numéro de trame machine (MFN) possiblement valide.

CVE-2026-102704 est le contrôle de permission. Copier par numéro de trame, plutôt que par grant reference, n'est permis que pour opérer sur la mémoire de l'appelant lui-même. Avant les correctifs, gnttab_copy_lock_domain() impose cette règle, aux lignes 2939 à 2946 du même fichier :

static int gnttab_copy_lock_domain(domid_t domid, bool is_gref,
                                   struct gnttab_copy_buf *buf)
{
    /* Only DOMID_SELF may reference via frame. */
    if ( domid != DOMID_SELF && !is_gref )
        return GNTST_permission_denied;

    buf->domain = rcu_lock_domain_by_any_id(domid);

gnttab_copy_one() n'atteint ce contrôle que lorsqu'il verrouille de nouveau les domaines, aux lignes 3140 à 3150. Ici, op est l'élément courant du lot, et src et dest sont les tampons source et destination en cache :

    if ( !src->domain || op->source.domid != src->ptr.domid ||
         !dest->domain || op->dest.domid != dest->ptr.domid )
    {
        gnttab_copy_release_buf(src);
        gnttab_copy_release_buf(dest);
        gnttab_copy_unlock_domains(src, dest);

        rc = gnttab_copy_lock_domains(op, src, dest);
        if ( rc < 0 )
            goto out;
    }

Un élément qui nomme les mêmes domaines que l'élément précédent saute ce bloc. Sa copie par numéro de trame n'est alors jamais confrontée à DOMID_SELF.

Comment la faille est-elle exploitée ?

Pour CVE-2026-102703 :

1. L'invité malveillant émet un lot GNTTABOP_copy. Un élément antérieur copie par grant reference, donc le cache contient une entrée de grant validée.
2. Un élément ultérieur du même lot copie par numéro de trame machine, donc Xen compare son numéro de trame avec l'entrée en cache.
3. La comparaison ne vérifie pas que l'entrée en cache était une entrée de trame. La grant reference antérieure est prise pour un numéro de trame, et Xen réutilise le tampon en cache.
4. La copie lit ou écrit alors une mémoire que l'invité ne peut pas légitimement adresser, appartenant à d'autres domaines, dont Dom0.

Pour CVE-2026-102704 :

1. L'invité malveillant émet un lot de copie. Un élément initial nomme un domaine étranger par grant reference, ce qui passe le contrôle, et Xen verrouille ce domaine.
2. Un élément ultérieur nomme le même domaine mais copie par numéro de trame. gnttab_copy_one() saute l'étape de verrouillage de domaine, donc le contrôle « seul DOMID_SELF peut référencer par trame » ne s'exécute jamais.
3. L'invité adresse directement par numéro de trame machine la mémoire d'un autre domaine, sans grant.

Aucun de ces chemins n'exige de configuration particulière de l'invité, seulement une grant table fonctionnelle. Aucune preuve de concept n'est publique, et les correctifs eux-mêmes documentent le comportement atteignable.

Comment l'attaque se déroule-t-elle ?

Un lot d'opérations de grant copy réutilise un état en cache, et l'un ou l'autre de deux contrôles manquants par élément laisse l'invité adresser la mémoire d'un autre domaine.

Que peut faire un attaquant ?

Dans les termes de l'avis, un invité malveillant peut lire et écrire la mémoire arbitraire appartenant à d'autres domaines, dont Dom0. C'est l'affirmation la plus forte que les sources autorisent.

En pratique, cet accès pourrait exposer des secrets présents dans la mémoire d'un autre invité ou modifier le code et les données d'un autre invité. Aucune source publique ne démontre une telle attaque. L'avis ne donne aucun score CVSS, et aucun abus réel n'est rapporté.

L'attaquant doit contrôler un invité sur un hôte non corrigé. Les hôtes qui n'exécutent que des invités de confiance ne sont exposés que si l'un de ces invités est d'abord compromis.

Pourquoi le correctif fonctionne-t-il ?

Le correctif de CVE-2026-102703 refuse la réutilisation du cache quand le mode d'adressage du nouvel élément diffère de celui en cache :

 static bool gnttab_copy_buf_valid(
     const struct gnttab_copy_ptr *p, const struct gnttab_copy_buf *b,
     bool has_gref)
 {
-    if ( !b->virt )
+    if ( !b->virt || b->have_grant != has_gref )
         return 0;
     if ( has_gref )
-        return b->have_grant && p->u.ref == b->ptr.u.ref;
+        return p->u.ref == b->ptr.u.ref;
     return p->u.gmfn == b->ptr.u.gmfn;
 }

Une grant reference ne peut plus être comparée à, ou confondue avec, un numéro de trame machine. Le contrôle est complet pour la faille signalée : le cache n'est consulté que lorsque les modes d'adressage correspondent.

Le correctif de CVE-2026-102704 retire le contrôle DOMID_SELF de gnttab_copy_lock_domain() et l'ajoute à gnttab_copy_claim_buf() :

         buf->ptr.u.ref = ptr->u.ref;
         buf->have_grant = 1;
     }
+    /* Only DOMID_SELF may reference via frame. */
+    else if ( ptr->domid != DOMID_SELF )
+        return GNTST_permission_denied;
     else
     {
         rc = get_paged_frame(ptr->u.gmfn, &buf->mfn, &buf->page,

gnttab_copy_claim_buf() s'exécute chaque fois qu'un élément ne peut pas réutiliser le tampon en cache. Le contrôle de permission ne dépend donc plus de l'exécution de l'étape de verrouillage de domaine.

Avec les deux correctifs, chaque élément du lot passe deux garde-fous avant de réutiliser quoi que ce soit :

Comment savoir si j'ai été compromis ?

Aucun indicateur n'est publié. L'avis ne décrit aucune signature de détection, et une lecture ou écriture de mémoire inter-domaines ne laisse aucune trace visible par l'invité victime.

Sur l'hôte, l'attaque est un invité émettant des hypercalls de grant copy ordinaires, qui ressemblent à une activité normale de grant table dans les journaux. Les hôtes ayant exécuté des invités non fiables avant d'appliquer le correctif doivent considérer les secrets des locataires comme potentiellement exposés. Demandez à votre fournisseur Xen ce qu'il propose pour la détection.

Chronologie

• 2015-01-29 : Le commit d28f42f2703e ajoute le cache de grant copy à l'arbre de Xen.
• 2015-10-07 : Le Xen Project étiquette Xen 4.6.0, la première version qui contient ce commit.
• 2026-11-03 : Le Xen Project publie XSA-523 version 2 publiquement à 12:00 UTC, avec les correctifs pour Xen 4.17 jusqu'à unstable et les deux identifiants CVE.

FAQ

Est-ce que cela concerne les hôtes KVM, Hyper-V ou VMware ?

Non. Les failles se trouvent dans le code de grant table de Xen, spécifique à cet hyperviseur. Les hôtes sur d'autres hyperviseurs ne sont pas concernés.

Les enregistrements CVE sont-ils publiés ?

Non. Au 4 novembre 2026, la base CVE ne contient aucun enregistrement pour CVE-2026-102703 ni CVE-2026-102704. L'avis nomme les deux identifiants, donc référez-vous à l'avis en attendant la publication des enregistrements.

Qui a trouvé la faille ?

Anthropic l'a découverte en utilisant Claude, et Stephan Lipp d'Ada Logics a validé la découverte, selon les crédits de l'avis. L'équipe CodeAnt AI Security Research l'a signalée indépendamment. Les correctifs portent une ligne « Assisted-by: Claude ». L'avis ne donne pas la date du premier signalement.

J'exécute une branche en fin de vie, 4.16 ou antérieur. Que faire ?

Le Xen Project ne fournit aucun correctif pour ces branches. Passez à une branche maintenue, 4.17 ou ultérieure, et appliquez-y les correctifs XSA-523.

Mon fournisseur de cloud exécute Xen. Dois-je agir ?

Vous ne pouvez pas corriger l'hôte d'un fournisseur depuis un invité. Demandez au fournisseur son état XSA-523, et considérez les secrets inter-locataires comme sa responsabilité jusqu'à sa confirmation du correctif.

Trouvez et corrigez vos hôtes Xen avant qu'un locataire ne les exploite

Les hôtes exécutant Xen pour des invités non fiables sont l'exposition ici, et l'attaquant est un locataire du même hôte, pas un scanner sur Internet. La découverte de surface d'attaque d'Ostorlab inventorie les serveurs et interfaces d'administration que vous exposez sur Internet, ce qui donne une première liste d'hôtes Xen dont vérifier l'état XSA-523. Les hôtes joignables uniquement depuis votre réseau interne demandent votre propre inventaire.

Références

• Xen Security Advisory 523 version 2, « arbitrary read/write via grant copy », publication publique 2026-11-03 : https://xenbits.xenproject.org/xsa/advisory-523.html (consulté le 4 novembre 2026)
• Correctif XSA-523 1, « gnttab: complete checking in gnttab_copy_buf_valid() », CVE-2026-102703 : https://xenbits.xenproject.org/xsa/xsa523-1.patch (consulté le 4 novembre 2026)
• Correctif XSA-523 2, « gnttab: move 'only local domain may copy by frame' check », CVE-2026-102704 : https://xenbits.xenproject.org/xsa/xsa523-2.patch (consulté le 4 novembre 2026)
• Copie de XSA-523 version 2 sur la liste OSS Security : https://www.openwall.com/lists/oss-security/2026/11/03/6 (consulté le 4 novembre 2026)
• Code source de Xen, xen/common/grant_table.c avant les correctifs XSA-523 (commit c89185286cbe) : https://github.com/xen-project/xen/blob/c89185286cbe74f584e2ddca9bfa6654a8600502/xen/common/grant_table.c (consulté le 4 novembre 2026)
• Commit Xen d28f42f2703e, « grant-table: defer releasing pages acquired in a grant copy », 2015-01-29 : https://github.com/xen-project/xen/commit/d28f42f2703e483116bafd2b0b76a32af67d83ad (consulté le 4 novembre 2026)
• Étiquette de version Xen 4.6.0, RELEASE-4.6.0, 2015-10-07 : https://github.com/xen-project/xen/releases/tag/RELEASE-4.6.0 (consultée le 4 novembre 2026)
• Xen Project, page du projet XCP-ng : https://xenproject.org/projects/xcp-ng/ (consultée le 4 novembre 2026)
• Documentation XCP-ng, « XCP-ng contains multiple components, built around the Xen Hypervisor » : https://docs.xcp-ng.org/ (consultée le 4 novembre 2026)
• Catalogue Known Exploited Vulnerabilities de la CISA, flux JSON, recherche des deux identifiants CVE : https://www.cisa.gov/sites/default/files/feeds/known_exploited_vulnerabilities.json (consulté le 4 novembre 2026)