Xen : trois use-after-free dans xen-netback et xen-blkback (XSA-526 à 528), un invité peut faire tomber l'hôte

Le 6 novembre 2026, l'équipe sécurité du projet Xen a publié trois avis d'un coup : XSA-526 (CVE-2026-100080), XSA-527 (CVE-2026-100081) et XSA-528 (CVE-2026-100082). Les trois décrivent un use-after-free dans les pilotes du noyau Linux qui servent les entrées-sorties des machines virtuelles depuis le domaine de contrôle, le dom0 : xen-netback pour le réseau et xen-blkback pour le stockage. Un invité malveillant peut les déclencher et, dans le scénario jugé le plus probable par l'équipe Xen, planter le noyau du dom0, donc faire tomber l'hôte Xen et toutes les machines virtuelles qu'il héberge. Le même jour, Greg Kroah-Hartman a publié sept noyaux stables qui ne contiennent que ces trois correctifs. Si vous faites tourner Xen ou XCP-ng sur un serveur dédié, voici comment savoir si vous êtes concerné, quoi mettre à jour, et pourquoi il faut garder une fenêtre de maintenance pour le 10 novembre.

Sources : XSA-526, XSA-527 et XSA-528 (projet Xen), index des avis de sécurité Xen, kernel.org, changelog Linux 7.3.3, Debian Security Tracker, documentation XCP-ng, blog XCP-ng, manuel xl-disk-configuration, politique de sécurité du projet Xen, options de ligne de commande de Xen, manuel xl.conf, guide XCP-ng sur la mémoire du dom0, prérequis XCP-ng, stockage XCP-ng, architecture Hyper-V (Microsoft Learn), linux-kvm.org, manuel VirtualBox.

Les trois avis en bref

Les trois failles ont le même profil : une condition de course entre la libération d'une structure mémoire au moment où un périphérique virtuel est démonté, et une lecture de cette même structure par un autre chemin du pilote. Le pilote accède alors à de la mémoire déjà libérée, et peut-être déjà réattribuée à autre chose : c'est la définition d'un use-after-free. Le déclencheur est à la main de l'invité, puisque c'est lui qui provoque la connexion, la déconnexion ou l'erreur qui lance le démontage.

Deux détails de forme en disent long sur l'urgence. D'abord, les avis sont sortis sans embargo : l'équipe Xen explique que des bugs très proches étaient déjà publics, ce qui rendait la période de confidentialité inutile. Ensuite, la correction côté Linux a été coordonnée le jour même : les versions stables 7.3.3, 6.18.62, 6.12.116, 6.6.162, 6.1.192, 5.15.225 et 5.10.274 sont toutes datées du 6 novembre sur kernel.org, et le changelog de la 7.3.3 ne contient que les trois commits correspondants, signés Juergen Gross (XSA-526 et 528) et Jan Beulich (XSA-527). XSA-526 et XSA-528 ont été signalées par Yehyeong Lee, de Hyundai Mobis ; XSA-527 par un chercheur connu sous le pseudonyme kerhunt.

Pourquoi un bug de pilote dans le dom0 fait tomber tout l'hôte

Dans l'architecture Xen, l'hyperviseur lui-même est minuscule : il gère le processeur et la mémoire, mais il ne contient aucun pilote de carte réseau ni de contrôleur de disque. Ce travail est délégué à un domaine privilégié, le dom0, qui exécute un noyau Linux complet. Chaque machine virtuelle invitée (domU) possède un pilote paravirtualisé côté invité, xen-netfront et xen-blkfront, qui dialogue à travers une mémoire partagée avec son pendant côté dom0, xen-netback et xen-blkback. Chaque paquet réseau et chaque bloc lu ou écrit par un invité traverse donc le noyau du dom0.

Cette conception a un revers : le noyau du dom0 est un point de défaillance unique. Si xen-netback déréférence un pointeur vers de la mémoire libérée, le résultat le plus courant est un kernel panic du dom0. L'hyperviseur reste techniquement en vie, mais plus aucune machine virtuelle n'a de réseau ni de disque, et en pratique le seul moyen de reprendre la main est un redémarrage complet de la machine physique. C'est pour cela que l'équipe Xen classe ces trois bugs en déni de service de l'hôte entier, et non d'un seul invité. Le scénario inverse existe aussi : en octobre, XSA-522 décrivait un backend capable de planter un invité via xen-netfront, mais la portée était alors limitée à cette seule machine virtuelle.

Le mécanisme précis diffère d'un avis à l'autre. Pour XSA-526, les compteurs de statistiques d'une interface virtuelle sont protégés par RCU, un mécanisme du noyau qui retarde la libération d'une structure tant qu'un lecteur peut encore la consulter. Quand la connexion du frontend échoue, par exemple parce que l'invité a écrit des valeurs invalides dans Xenstore, le démontage de la file libère ces compteurs sans attendre la période de grâce RCU. Une lecture des statistiques via sysfs à ce moment-là, le genre d'opération qu'un agent de supervision fait toutes les quelques secondes, touche de la mémoire libérée. Pour XSA-527, c'est la liste des adresses multicast de l'interface qui est libérée avant que le traitement des paquets en émission et en réception ne soit arrêté ; une recherche dans cette liste depuis le chemin d'émission peut alors tomber sur un pointeur mort. Pour XSA-528, xen-blkback ne synchronise pas la lecture des statistiques d'entrées-sorties d'un disque virtuel avec la libération de la structure qui les contient.

Pourquoi une fuite d'informations et, pour XSA-527, une élévation de privilèges sont-elles évoquées ? Parce qu'une zone libérée peut être réattribuée à un autre usage entre la libération et la lecture fautive. Le pilote lit alors des données qui ne lui appartiennent plus, et dans le cas d'une liste chaînée parcourue par le chemin d'émission, un attaquant qui contrôle le contenu réattribué pourrait en théorie orienter le noyau. L'équipe Xen juge ce dernier scénario très peu probable, mais ne l'écarte pas. Pour un hébergeur de machines virtuelles tierces, l'hypothèse à retenir reste le déni de service : un locataire hostile, ou une VM compromise, peut couper tous ses voisins.

Xen face à KVM, Hyper-V, ESXi et VirtualBox : où vivent les pilotes ?

La question posée par ces trois avis dépasse Xen. Dans toute plateforme de virtualisation, un système d'exploitation privilégié porte les pilotes du matériel réel, et un bug dans ce code touche toutes les VMs de la machine hôte. Ce qui change d'un hyperviseur à l'autre, c'est l'endroit où ce code s'exécute, donc ce qu'un correctif comme XSA-526 à 528 implique pour l'exploitation du serveur.

Deux enseignements pour qui compare les plateformes avant d'installer un hyperviseur sur un serveur dédié. D'abord, Hyper-V reproduit presque trait pour trait l'architecture de Xen : la documentation Microsoft décrit une partition racine qui gère les pilotes de périphériques et qui est la seule à accéder au matériel, pendant que les partitions enfants n'en voient qu'une vue virtuelle. Un bug dans les pilotes de la partition racine aurait donc le même effet qu'un bug dans xen-netback. Ensuite, KVM n'a pas de dom0 séparé parce que le noyau hôte est à la fois l'hyperviseur et le porteur des pilotes : la surface est la même, simplement regroupée dans un seul noyau, et c'est pour cela que notre tutoriel sur la mise à jour de Proxmox VE impose les mêmes redémarrages à chaque noyau. Côté matériel, Xen garde une particularité : il peut exécuter des invités paravirtualisés sans extensions de virtualisation du processeur, là où KVM et Hyper-V exigent Intel VT-x ou AMD-V. En pratique, XCP-ng les impose aussi, avec les tables de pages imbriquées (EPT ou NPT), et demande de les activer dans le BIOS du serveur, où elles sont parfois désactivées par défaut. Pour un panorama plus large, notre guide Proxmox vs VMware détaille ce que chaque hyperviseur demande en RAM, en processeurs et en licence.

Êtes-vous concerné ?

La question se résume à une seule : votre noyau Linux sert-il des entrées-sorties à d'autres machines virtuelles Xen ? Sont concernés :

• Le dom0 de tout hôte Xen installé à la main sur un serveur dédié, quelle que soit la distribution (Debian, Ubuntu, Alpine, Arch, noyau compilé soi-même) ;
• Un domaine pilote (driver domain) dédié au réseau ou au stockage, puisqu'il exécute les mêmes backends ;
• Le dom0 de XCP-ng et de XenServer, dont le noyau Linux est fourni par l'éditeur et intègre ces pilotes.

Ne sont pas concernés par ces trois avis : les machines virtuelles invitées elles-mêmes (elles n'exécutent que xen-netfront et xen-blkfront), les hôtes KVM comme Proxmox VE ou Incus, dont le noyau ne charge jamais xen-netback, et les VPS Linux KVM d'ElypseCloud, qui sont des invités KVM et non des hôtes Xen. Les hôtes Xen qui utilisent un backend en espace utilisateur fourni par QEMU, qnic pour le réseau et qdisk pour le stockage, ne passent pas par les pilotes vulnérables pour ces périphériques, ce que l'équipe Xen cite d'ailleurs comme mesure de contournement.

Pour vérifier concrètement sur une machine, connectez-vous en SSH au dom0 :

cat /sys/hypervisor/type
lsmod | grep -E 'xen_netback|xen_blkback'
grep -E 'CONFIG_XEN_NETDEV_BACKEND|CONFIG_XEN_BLKDEV_BACKEND' /boot/config-$(uname -r)
uname -r

La première commande renvoie xen si la machine tourne au-dessus de l'hyperviseur Xen, qu'elle soit dom0 ou invité. La deuxième liste les modules backend chargés : si xen_netback ou xen_blkback apparaissent, vous servez des invités et vous êtes concerné. Si rien ne s'affiche, la troisième commande lève le doute pour les noyaux où ces pilotes sont compilés en dur (valeur y) plutôt qu'en module (m). La dernière donne la version du noyau à comparer au tableau ci-dessous.

La branche 7.2 n'apparaît pas dans ce tableau pour une raison simple : kernel.org la marque en fin de vie depuis la version 7.2.15 du 1er novembre, et elle ne recevra pas ces correctifs. Un dom0 qui tourne encore sur un noyau 7.2 compilé maison doit passer en 7.3. Par ailleurs, un noyau d'une distribution porte rarement un numéro identique à la branche amont : Debian, Ubuntu ou Red Hat rétroportent les correctifs dans leurs propres paquets. Dans ce cas, c'est l'avis de sécurité de la distribution qui fait foi, pas le numéro affiché par uname -r.

Mettre à jour le noyau du dom0 et redémarrer

Il n'y a pas de correctif à chaud pour ces trois bugs : le pilote corrigé est dans un nouveau noyau, et un nouveau noyau ne se charge qu'au redémarrage du dom0, donc de la machine physique et de toutes ses VM. La séquence est toujours la même, quelle que soit la distribution.

1. Vérifiez vos sauvegardes avant d'y toucher. Un dom0 qui ne redémarre pas sur un nouveau noyau se récupère par la console distante et l'entrée GRUB précédente, mais il vaut mieux ne pas découvrir que la sauvegarde de la veille est vide à ce moment-là. Notre guide sur les sauvegardes et la haute disponibilité d'un serveur dédié détaille les options.
2. Installez le noyau corrigé. Sur un dom0 Debian ou Ubuntu, sudo apt update && sudo apt full-upgrade suffit dès que le paquet linux-image corrigé est disponible dans les dépôts. Si vous compilez votre noyau depuis les sources stables, passez à la version du tableau pour votre branche, ou appliquez les fichiers xsa526-linux.patch, xsa527-linux.patch et xsa528-linux.patch joints aux avis.
3. Arrêtez ou migrez les invités proprement, avec xl list pour les recenser et xl shutdown pour chacun, ou une migration à chaud vers un second hôte si votre installation le permet.
4. Redémarrez le dom0, puis contrôlez avec uname -r que le noyau attendu est actif et avec lsmod que les backends se sont rechargés avant de relancer les machines virtuelles. Une fois la première VM démarrée, vérifiez depuis son shell que le réseau répond et que la résolution DNS fonctionne : c'est le test le plus rapide pour confirmer que xen-netback sert à nouveau les invités.

Au 8 novembre, l'état des paquets Debian illustre le décalage habituel entre l'amont et les distributions : le tracker de sécurité Debian marque les trois CVE comme corrigées uniquement dans sid avec le paquet 7.3.3-1, tandis que Debian 12 Bookworm (noyau 6.1.190-1 dans la branche sécurité) et Debian 13 Trixie (6.12.115-2) restent marquées vulnérables, sans version corrigée annoncée. Pour Ubuntu, Alpine ou toute autre distribution, consultez le tracker de l'éditeur plutôt que de supposer qu'une mise à jour générale du système a suffi. Si vous administrez aussi des machines qui ne sont pas des hôtes Xen, la méthode décrite dans notre actualité sur la faille TCP CVE-2026-98432 du noyau Linux reste valable : vérifier la version, patcher, redémarrer, revérifier.

XCP-ng 8.3 : la procédure côté Vates

Sur XCP-ng, vous ne choisissez pas votre noyau : le dom0 reçoit un noyau Linux empaqueté par Vates, mis à jour via yum et annoncé sur le blog du projet avec un avis de sécurité Vates (VSA). Au 8 novembre, le blog XCP-ng n'a pas encore publié de mise à jour mentionnant XSA-526, 527 ou 528. Les deux derniers lots datent du 3 novembre (Xen synchronisé sur la version 4.17.7-4 de XenServer, qui intègre le correctif de XSA-523) et du 4 novembre (noyau du dom0 corrigé pour CVE-2026-98432, avis VSA-2026-056). Tous deux exigent un redémarrage des hôtes. Si vous ne l'avez pas encore fait, vous avez donc déjà un redémarrage en attente, et il est raisonnable de le regrouper avec celui des trois nouveaux avis dès que Vates publiera le noyau correspondant.

La documentation XCP-ng fixe la méthode, à suivre à la lettre dans un pool :

1. Toujours commencer par le maître du pool : un membre ne doit jamais avoir une version supérieure au maître, sous peine de ne plus pouvoir s'y reconnecter.
2. Ne jamais lancer la mise à jour depuis un shell ouvert dans xsconsole ni depuis la console distante VNC de l'hôte : la documentation prévient que la mise à jour peut redémarrer ces consoles, tuer le processus de mise à jour et laisser le système dans un état incohérent. Passez par une session SSH.
3. Vérifier qu'aucune tâche ne tourne avec xe task-list, puis sortir l'hôte du service et déplacer ses VM :

xe host-disable uuid=<uuid de l'hôte>
xe host-evacuate uuid=<uuid de l'hôte>
yum update
reboot

Après le redémarrage, si l'hôte ne s'est pas réactivé seul, lancez xe host-enable uuid=<uuid de l'hôte> et passez au membre suivant. La documentation précise qu'un redémarrage est indispensable dès qu'un paquet kernel ou xen-* a été mis à jour ; xe-toolstack-restart, qui redémarre seulement la pile de gestion sans toucher aux VM, ne suffit pas pour un correctif de noyau. Les pools XOSTOR ont une étape supplémentaire sur les paquets LINSTOR, décrite dans la même page.

En attendant le correctif : réduire l'exposition

Les avis proposent deux contournements, honnêtes mais lourds. Le premier consiste à remplacer les backends noyau par leurs équivalents en espace utilisateur dans QEMU : qnic pour le réseau, qdisk pour le stockage. Le pilote vulnérable n'est alors plus sur le chemin de ces périphériques, et un plantage de QEMU n'emporte que l'invité concerné, pas le dom0. Côté stockage, c'est l'option backendtype=qdisk de la définition de disque dans la configuration xl d'un invité, documentée dans le manuel xl-disk-configuration. Le second consiste à confier les backends à un domaine pilote dédié par invité, via l'option backend= des définitions de disque et d'interface réseau, qui désigne par défaut le domaine 0 : si un locataire parvient à déclencher le bug, il ne plante que son propre domaine pilote. Ces deux contournements s'adressent à un Xen installé à la main et configuré avec xl ; sur XCP-ng, la réponse attendue reste le noyau corrigé empaqueté par Vates.

Pour la plupart des administrateurs, la vraie question est celle de la confiance accordée aux invités. Si toutes les machines virtuelles de l'hôte sont les vôtres, l'attaquant doit d'abord compromettre l'une d'elles, et le risque principal est un déni de service de votre propre infrastructure : le correctif peut attendre une fenêtre de maintenance planifiée, à condition qu'elle arrive vite. Si vous hébergez des VM pour des tiers, des clients ou des équipes dont vous ne maîtrisez pas le contenu, chaque locataire dispose d'un bouton pour couper tous les autres : traitez le sujet comme une urgence. Entre les deux, limiter la supervision qui lit les statistiques sysfs en boucle ne constitue pas une protection, puisque la fenêtre de course existe de toute façon dans le chemin d'émission pour XSA-527.

Au-delà du correctif : un dom0 dimensionné et isolé

Les trois avis rappellent que le dom0 n'est pas une machine virtuelle Linux comme les autres. C'est le système d'exploitation qui détient les pilotes, l'accès root à l'hyperviseur et la pile de gestion, xl sur un Xen installé à la main, XAPI sur XCP-ng. Quelques réglages, tous documentés par le projet Xen ou par Vates, réduisent à la fois le risque de plantage et le temps de retour en service après un redémarrage de sécurité.

• Une RAM fixe pour le dom0. Chaque disque virtuel et chaque interface réseau servis à une VM consomment de la mémoire dans le dom0, puisque leur backend y tourne. La documentation Xen recommande de fixer cette mémoire au démarrage avec l'option dom0_mem de la ligne de commande de l'hyperviseur, par exemple dom0_mem=4096M,max:4096M, et de couper l'autoballooning dans /etc/xen/xl.conf avec autoballoon="off", faute de quoi xl peut reprendre de la mémoire au dom0 pour démarrer de nouveaux invités. XCP-ng chiffre le besoin : 2 Gio au minimum, 4 Gio jusqu'à 64 Gio de RAM sur l'hôte, 8 Gio jusqu'à 128 Gio, 16 Gio au-delà et 32 Gio à partir de 1 Tio, à régler avec /opt/xensource/libexec/xen-cmdline --set-xen dom0_mem=4096M,max:4096M puis un redémarrage. Un dom0 à court de mémoire échoue sur des opérations banales, la migration à chaud en tête.
• Des processeurs réservés. Par défaut, le dom0 reçoit autant de vCPU que le serveur compte de processeurs logiques. L'option dom0_max_vcpus permet de le borner, par exemple dom0_max_vcpus=4-8, et dom0_vcpus_pin épingle chacun de ses vCPU sur un cœur physique, ce qui évite qu'une VM gourmande ne ralentisse les backends qui servent tous les autres invités.
• Un accès root verrouillé. Quiconque obtient un shell root sur le dom0 contrôle toutes les VMs de la machine. La documentation XCP-ng rappelle que le réseau de gestion de l'hôte ne doit jamais porter d'adresse IP publique ; sur un Xen maison, les réflexes de notre tutoriel pour sécuriser SSH s'appliquent au dom0 mot pour mot : clé plutôt que mot de passe, pas de connexion root directe, pare-feu restreint aux adresses d'administration.
• Des scripts de supervision conscients du risque. Les scripts qui lisent les compteurs d'interfaces et de disques virtuels dans sysfs ne causent pas XSA-526 ni XSA-528, mais ils en sont l'autre moitié : l'invité ouvre la fenêtre de course, le lecteur de statistiques tombe dedans. Un hôte dont les compteurs sont lus chaque seconde offre donc plus d'occasions à un attaquant qu'un hôte silencieux, sans qu'il soit possible de s'en protéger autrement que par le noyau corrigé.
• Des sauvegardes hors de l'hôte et de l'espace disque pour le dom0. xen-blkback sert indifféremment un volume LVM local, une image sur un partage NFS hébergé par un NAS ou une cible iSCSI, autant de types de dépôts pris en charge par XCP-ng. Un backup des VMs qui vit sur le même serveur physique ne vaut rien si le dom0 ne redémarre plus : visez une copie sur un second serveur ou un NAS distinct, et surveillez l'espace disque libre du dom0 lui-même, où s'accumulent journaux et paquets de mise à jour. Pour mémoire, XCP-ng demande 46 Go de stockage local au minimum et en recommande 70. Notre guide sur les sauvegardes d'un serveur dédié compare les approches.

Ces réglages ne remplacent pas le correctif, mais ils décident de ce qui se passe à 3 heures du matin quand un dom0 tombe : un hôte dont la mémoire est fixée, dont les VMs sont sauvegardées ailleurs et dont l'accès console est prêt redémarre en quelques minutes ; un hôte configuré à la va-vite peut coûter une nuit. Les administrateurs qui dimensionnent un serveur dédié pour plusieurs machines virtuelles retrouveront la même logique, côté KVM, dans notre guide pour dimensionner Proxmox VE sur un serveur dédié.

XSA-529 et XSA-530 arrivent le 10 novembre

L'index des avis Xen affiche déjà deux numéros supplémentaires, XSA-529 et XSA-530, marqués « assigned, but embargoed » avec une publication prévue le 10 novembre 2026 à 18 h UTC, soit 19 h en France. Rien n'est connu de leur contenu ni de leur gravité : la politique de sécurité du projet Xen n'autorise, avant la levée d'embargo, que la diffusion de l'existence de l'avis, de son numéro et de la date de publication prévue, et interdit aux membres de la liste de prédivulgation de parler de l'impact, de la portée ou de la nature de la faille. Il serait imprudent d'en déduire qu'il s'agit encore de pilotes Linux ; ce peut aussi bien être l'hyperviseur lui-même.

Ce calendrier s'ajoute à un début de mois déjà chargé pour les hôtes Xen. Le 3 novembre, XSA-523 (CVE-2026-102703 et CVE-2026-102704) révélait une erreur dans la mise en cache des opérations de copie par références d'octroi (grant copy) : un invité malveillant pouvait lire et écrire la mémoire d'autres domaines, dom0 compris, sur toutes les versions de Xen depuis la 4.6, sans aucun contournement connu. XCP-ng l'a corrigée le jour même. En dix jours, un administrateur Xen consciencieux aura donc enchaîné trois redémarrages de ses hôtes, et possiblement un quatrième le 10 novembre. La bonne réponse n'est pas de sauter l'un d'eux, mais de regrouper : si le noyau corrigé pour XSA-526 à 528 n'est pas encore disponible pour votre distribution ou pour XCP-ng le 10 au soir, attendez quelques heures pour lire les deux nouveaux avis et appliquez tout en une seule fenêtre.

Lexique : les termes des avis Xen

Héberger son hyperviseur sur un serveur dédié

Ces trois avis rappellent ce qui distingue un hôte de virtualisation d'un serveur ordinaire : une faille dans le noyau de l'hôte touche toutes les charges qu'il porte, et un redémarrage de sécurité n'est jamais anodin. Sur un serveur dédié ElypseCloud, vous installez l'hyperviseur de votre choix, Xen, XCP-ng ou Proxmox VE, vous y faites cohabiter vos environnements de production et de test, et vous décidez seul du calendrier de vos mises à jour. Si vous préférez apporter votre propre hardware, le housing en datacenter offre la même liberté avec un accès distant pour reprendre la main après un redémarrage qui tourne mal. Pour les équipes qui comparent les plateformes, nos guides sur la mise à jour et la sécurisation de Proxmox VE et sur Incus sans Proxmox décrivent les mêmes réflexes côté KVM, et les premiers réglages de sécurité d'un serveur dédié s'appliquent au dom0 comme à n'importe quelle machine exposée.