Januscape CVE-2026-53359 : échappement du mode invité KVM

Accédez directement au résumé généré par l'IA de cet article de blog

En bref

Aller directement à la version longue ↓

Description : Januscape (CVE-2026-53359) est une vulnérabilité de type « use-after-free » affectant la MMU fantôme KVM/x86 du noyau Linux. Un invité malveillant peut amener KVM à réutiliser une page fantôme mise en cache qui ne correspond plus au mappage en cours de construction, ce qui laisse une entrée de mappage inverse obsolète pointant vers de la mémoire que KVM libérera par la suite. Aller à la version longue →

Impact : Le résultat observable et fiable est un plantage de l’hôte. Des recherches publiques décrivent une évasion complète de l’invité vers l’hôte : du code provenant d’un invité malveillant s’exécute sur l’hôte en tant que root. Nous avons confirmé de manière indépendante la corruption de la mémoire de l’hôte et la primitive de déni de service sur AlmaLinux 9 et Ubuntu 24.04, bien que nous n’ayons pas reproduit la chaîne d’évasion complète. Sur les systèmes de la famille RHEL où /dev/kvm est accessible à tous, ce même bug permet une élévation locale des privilèges jusqu'au niveau root. Accéder à la version longue →

Statut : Corrigé en amont (commit 81ccda30b4e8, intégré à la branche principale en juin 2026). Le NVD a publié le CVE le 4 juillet 2026, et l’embargo a été levé le 6 juillet. Il s’agissait d’une soumission « zero-day » au kvmCTF ; pour les défenseurs aujourd’hui, il s’agit d’une vulnérabilité « N-day » accompagnée d’une preuve de concept publique. Aller à la version longue →

Gravité : NVD n'avait pas attribué de score CVSS au moment de la publication. L'absence de score ne signifie pas que l'impact est faible. Considérez-le en interne comme élevé et n'attendez pas l'apparition d'une case colorée. Accéder à la version complète →

Qui est concerné : les hôtes KVM/x86, Intel et AMD, qui exposent la virtualisation imbriquée aux machines invitées. La faille nécessite un élément supplémentaire en plus des droits root de la machine invitée : la virtualisation imbriquée. Aller à la version longue →

Vulnérabilité associée : Januscape nécessite un deuxième correctif, CVE-2026-46113, pour être complètement neutralisé. Le simple fait d'appliquer le correctif pour la première vulnérabilité ne suffit pas à bloquer Januscape. Aller à la version longue →

Procédez dès maintenant comme suit : appliquez un correctif sur les hôtes KVM concernés, soit en installant un noyau corrigé, soit en utilisant un correctif ne nécessitant pas de redémarrage. Les hôtes qui n’hébergent aucune machine virtuelle peuvent décharger et bloquer les modules KVM. Les hôtes qui hébergent des machines virtuelles mais n’ont pas besoin de la virtualisation imbriquée doivent la désactiver, ce qui supprime la voie d’échappement pour les invités non fiables. Les hôtes qui ont besoin des deux ne peuvent pas être sécurisés uniquement par la configuration. Accéder à la version longue →

Vous avez besoin d'appliquer des correctifs aux hôtes KVM sans redémarrer chaque machine virtuelle ?

KernelCare applique les correctifs de sécurité du noyau Linux sans temps d'arrêt, sans perturbation des charges de travail et sans fenêtres de maintenance d'urgence.
État d'avancement de KernelCare : au 7 juillet 2026, des correctifs sans redémarrage couvrant à la fois la vulnérabilité CVE-2026-53359 et la vulnérabilité associée requise CVE-2026-46113 sont disponibles pour plusieurs familles de noyaux, et d'autres sont en cours de développement. L'état complet des versions et les balises K sont répertoriés ci-dessous.

Télécharger KernelCare →

La version longue

Januscape remet en cause le principe même de la virtualisation.

Une machine virtuelle invitée peut être compromise, contrôlée par le client, obsolète, intentionnellement malveillante ou simplement mal configurée. Dans aucun de ces cas, elle ne devrait pouvoir accéder à la mémoire de l’hôte. Le rôle de KVM est de traduire la mémoire de la machine virtuelle invitée en toute sécurité tout en préservant cette séparation. Januscape perturbe le mécanisme de gestion sous-jacent à cette traduction.

Le bogue se trouve dans le fichier arch/x86/kvm/mmu/mmu.c, au sein de la MMU fantôme de KVM. Ce code gère les structures de tables de pages côté hôte qui mappent les adresses utilisées par un invité vers la mémoire autorisée par l’hôte. Dans le cadre d'une séquence contrôlée de modifications du mappage de l'invité, KVM réutilise une page fantôme existante même si son rôle enregistré ne correspond plus au mappage en cours de construction. Cette réutilisation laisse une entrée de mappage inverse pointant vers une structure que KVM libère par la suite, et un parcours ultérieur du mappage inverse déréférence la page libérée.

Une précision d’emblée, car cela détermine qui est exposé. Il ne s’agit pas d’une « data race » au sens classique du terme, et ce n’est pas le même défaut que celui de son « frère ». Le noyau classe Januscape comme un « use-after-free » causé par un rôle inattendu de la page fantôme. Le déclencheur implique la modification asynchrone d’un mappage d’invité, depuis l’extérieur du « page walk » propre à l’invité ; il faut donc une pression temporelle pour atteindre la fenêtre. Mais la cause première est une comparaison manquante, et non un bug de verrouillage. Gardez bien cette distinction à l’esprit, car le correctif et les mesures d’atténuation en découlent.

Comment fonctionne Januscape ?

En résumé :

[Guest with root + nested virtualization exposed]
│  forces KVM back through the legacy shadow MMU
▼
[Guest creates a large 2 MB mapping → KVM builds a direct shadow page]
│
▼
[Guest rewrites the mapping to a 4 KB page-table path]
│  new mapping needs a non-direct (direct=0) page
▼
[kvm_mmu_get_child_sp() reuses the old direct page – gfn matches, role NOT compared]
│
▼
[Cleanup computes the wrong frame number → reverse-map entry not removed]
│
▼
[Shadow page freed; stale reverse-map entry left behind]
│  later rmap walk (dirty logging / MMU-notifier invalidation)
▼
[Use-after-free write of a fixed marker into freed memory]
▼
[Host crash (public PoC)  →  or guest-to-host escape, root on host (withheld exploit)]

Examen détaillé de ce processus : la séquence commence par une entrée dans le répertoire des pages de l'invité décrivant un mappage de grande taille (2 Mo). KVM construit une page `kvm_mmu_page` couvrant 512 entrées individuelles de 4 Ko et, comme le mappage de l'invité est une grande page contiguë, marque la page fantôme comme « directe ».

Le mappage est alors modifié en dehors du flux d'exécution normal de l'invité. Au lieu d'une grande page, la même entrée du répertoire de pages pointe désormais vers une autre table de pages contenant des mappages individuels de 4 Ko. KVM a besoin d'un autre type de page fantôme pour cette structure : alors que l'originale a un rôle direct, le nouveau mappage nécessite un rôle non direct. Le chemin vulnérable kvm_mmu_get_child_sp() ne compare pas ce rôle complet avant de décider de réutiliser la page existante. Le numéro de trame correspondant étant identique, la page est acceptée, et KVM installe une nouvelle entrée feuille et enregistre une entrée de mappage inverse pour la trame résolue lors de la nouvelle itération.

Le problème apparaît lors du nettoyage. Comme la page parente réutilisée prétend toujours être directe, KVM calcule le cadre de la nouvelle entrée de 4 Ko selon la formule sp->gfn + index, au lieu d’utiliser la traduction mise en ombre stockée. Il recherche alors l’entrée de la carte inverse sous un numéro de cadre erroné et ne parvient pas à la supprimer. La page mise en ombre est libérée, mais l’entrée obsolète de la carte inverse subsiste. Toute opération ultérieure parcourant cette carte inverse déréférence une entrée située dans la page libérée. Le noyau identifie la journalisation des modifications (« dirty logging ») et l’invalidation par le notificateur MMU (« MMU-notifier invalidation ») comme les opérations à l’origine de ce phénomène.

Un détail permet d’expliquer à la fois la preuve de concept (PoC) rendue publique et l’exploit qui n’a pas été divulgué. Lors du « teardown », KVM écrit une constante de marqueur fixe dans une zone de mémoire susceptible d’être réallouée. Il s’agit bien d’une écriture de type « use-after-free », mais elle est soumise à une contrainte : la valeur fixe doit être placée à une adresse que l’attaquant doit aligner avec un objet utile du noyau. Il est difficile de garantir cet alignement de manière fiable, ce qui explique pourquoi le code public se contente de provoquer le plantage de l’hôte et pourquoi l’exploit complet n’a pas été divulgué.

L'invité accède à ce code via la virtualisation imbriquée. Sur un hôte moderne exécutant des invités en mode de pagination matérielle (EPT sur Intel, NPT sur AMD), la MMU fantôme logicielle n'est généralement pas sollicitée. C'est le fait d'exposer la virtualisation imbriquée qui oblige KVM à repasser par l'ancienne MMU fantôme, où se trouve Januscape. C'est la raison pour laquelle un hôte peut paraître moderne tout en entrant pleinement dans le champ d'application.

Ce que nous avons confirmé

Nos tests ont confirmé que cette vulnérabilité est exploitable aussi bien sur un noyau Enterprise Linux que sur Ubuntu 24.04. Nous avons reproduit l’attaque par déni de service (DoS) sur l’hôte ainsi que la corruption de mémoire. Nous n’avons pas exécuté l’exploit de type « escape » de bout en bout, que le chercheur a choisi de ne pas divulguer.

Sous AlmaLinux 9 avec le noyau 5.14.0-687.5.3.el9_8, le déclencheur a provoqué un bogue fatal du noyau dans la fonction pte_list_remove(). L'hôte est entré en état de panique en l'espace de quelques secondes à quelques minutes alors que le processus actif était qemu-kvm. Il s'agit là d'une attaque par déni de service de l'hôte, déclenchée de manière fiable par un invité, sur le noyau testé.

Sous Ubuntu 24.04 avec le noyau 6.8.0-111-generic, cette même corruption a généré un avertissement plutôt qu'une panique immédiate. Le noyau a signalé une incompatibilité GFN dans la fonction `kvm_mmu_page_set_translation()` – la confusion des trames, cause première du problème, devenant alors visible – suivie d’un avertissement en aval dans la fonction `pte_list_remove()`. L’hôte a survécu car, sur cette version d’Ubuntu, ces contrôles de cohérence relèvent de la catégorie des avertissements plutôt que des contrôles de bogues fatals ; il a donc continué à fonctionner avec un état de MMU fantôme corrompu (Tainted : G W).

Un avertissement qui subsiste ne signifie pas que tout est en ordre. Cela signifie que l'état de traduction géré par l'hôte est devenu incohérent et que la machine a réussi tant bien que mal à passer outre sa propre assertion. Pour permettre une collecte contrôlée des fichiers de vidage mémoire, vous pouvez faire en sorte que les reproductions de type « avertissement » entraînent un arrêt fatal :

sudo sysctl kernel.panic_on_warn=1

Il s'agit d'un outil de test et d'aide pour vmcore. Ce n'est pas une mesure d'atténuation.

Ce que modifie le correctif « Upstream »

Ce correctif ajoute la vérification du rôle manquante avant que KVM ne réutilise une page fantôme. Avant l'application du correctif, un numéro de trame d'invité correspondant pouvait suffire pour accepter une page existante. Désormais, la fonction `kvm_mmu_get_child_sp()` compare le rôle complet de la page (role.word) au numéro de trame, et ne réutilise une page que lorsque les deux correspondent. Lorsque le rôle est incompatible, KVM supprime l’entrée existante et crée la page fantôme correcte au lieu de conserver une interprétation obsolète. Ce correctif a été rédigé par Paolo Bonzini et Sean Christopherson, responsables de la maintenance de KVM.

D'un point de vue conceptuel :

Before:  matching gfn → reuse shadow page → role mismatch ignored → stale reverse map → use-after-free
After:   matching gfn → compare role.word → reject incompatible page → zap old entry → build correct page

Le correctif en amont pour Januscape correspond au commit 81ccda30b4e83d8f5cc4fd50503c44e3a33abfeb. Le correctif associé, celui concernant la vulnérabilité CVE-2026-46113, correspond au commit 0cb2af2ea66ad8ff195c156ea690f11216285bdf. Chacun d'entre eux corrige un cas différent de « stale-shadow-page » ; ils doivent donc tous deux être intégrés dans un noyau corrigé.

Les registres des fournisseurs et des correctifs sans redémarrage ne les identifient pas toujours séparément. Certaines versions antérieures de KernelCare intégraient le correctif du rôle Januscape en tant qu’élément associé non référencé par un CVE, sous l’identifiant CVE-2026-46113 ; par conséquent, l’absence d’une chaîne CVE-2026-53359 distincte ne signifie pas en soi que le correctif du rôle est manquant.

The Sibling : CVE-2026-46113

Januscape n'est pas apparu isolément. Avant sa correction, les développeurs du noyau avaient corrigé la vulnérabilité CVE-2026-46113, une autre faille de type « use-after-free » liée à la pagination fantôme KVM/x86, située dans la même partie de la MMU. Ces deux failles doivent être abordées conjointement sans jamais être confondues, car les deux correctifs comblent des failles différentes et un hôte a besoin des deux.

La vulnérabilité CVE-2026-46113 survient lorsque KVM réutilise une page fantôme créée pour un numéro de trame d'invité incorrect. Le mappage d'un invité change d'une entrée de machine virtuelle à l'autre ; KVM continue d'utiliser une page fantôme créée pour le mappage d'origine, et une nouvelle entrée de table de pages est enregistrée sous une trame située en dehors de la plage que KVM explore par la suite lors du nettoyage. Le nettoyage ne la détecte pas. La page fantôme est libérée. L'entrée obsolète de la table de mappage inverse subsiste. Un parcours ultérieur de la table de mappage inverse déréférence la page libérée.

Le correctif CVE-2026-46113, commit 0cb2af2ea66a, a ajouté une vérification du numéro de trame de l'invité : lorsque KVM détecte qu'une page existante appartient à une trame incorrecte, il supprime l'ancienne entrée au lieu de la réutiliser. Januscape a démontré que cette vérification n'était pas suffisante.

Dans le chemin Januscape, le numéro de trame peut sembler correct. La divergence réside dans le rôle de la page d'ombre :

Le mappage d'origine crée une page d'ombre directe pour un mappage volumineux de 2 Mo (direct=1).
Le client modifie ce mappage pour qu'il pointe vers une table de pages de niveau inférieur.
Le nouveau chemin nécessite une page d'ombre non directe pour les mappages de 4 Ko (direct=0).
KVM trouve un numéro de trame correspondant et réutilise l'ancienne page.
Le cadre correspond, mais l'interprétation de la page ne correspond pas.

La vulnérabilité CVE-2026-46113 a permis de résoudre le problème lié à la « wrong-frame ». Januscape a permis de résoudre le problème lié au « wrong-role ». Le correctif précédent s'inscrit dans ce contexte ; Januscape est la vulnérabilité dont traite cet article. L'application du correctif précédent ne suffit pas à elle seule à résoudre le problème lié à Januscape.

Qui est concerné ?

Januscape affecte les systèmes Linux utilisant la MMU « shadow » KVM/x86. Cela concerne aussi bien les hôtes Intel que les hôtes AMD, car le code vulnérable se trouve dans la logique partagée de la MMU KVM/x86 plutôt que dans kvm_intel ou kvm_amd uniquement. Le chercheur a démontré que le même déclencheur fonctionnait sur les deux, en modifiant uniquement les bits de la table de pages spécifiques à l'architecture. Plusieurs facteurs déterminent le degré de vulnérabilité d'un hôte donné.

Hyperviseurs KVM exécutant des machines invitées avec virtualisation imbriquée. Priorité maximale. Une machine invitée malveillante ou compromise disposant des droits root dans sa propre machine virtuelle peut accéder au chemin du noyau hôte vulnérable via la virtualisation imbriquée. Il s’agit du scénario d’évasion « de la machine invitée vers l’hôte » ; c’est là qu’une seule instance louée peut provoquer le plantage de l’hôte physique ou, à l’aide de l’exploit non divulgué, prendre le contrôle des machines invitées colocalisées. Dans notre laboratoire, la reproduction de la machine invitée charge un module qui gère l'état brut VMX/SVM, ce qui correspond exactement au chemin de virtualisation imbriquée.

Hôtes KVM qui exécutent des machines invitées sans toutefois exposer la virtualisation imbriquée. Le risque lié au vecteur « machine invitée vers hôte » est moindre, car la MMU logicielle fantôme n’est pas activée de manière forcée pour ces machines invitées. Vérifiez que la virtualisation imbriquée est bien désactivée avant de vous fier à cette affirmation.

Hôtes disposant de KVM mais sans machine virtuelle en cours d'exécution. Ceux-ci peuvent tout de même exposer un chemin d'accès local si un utilisateur local non fiable parvient à ouvrir /dev/kvm et à piloter directement KVM. Si KVM n'est pas utilisé, déchargez et bloquez les modules.

Conteneurs et CloudLinux LVE. Un conteneur standard ne dispose pas automatiquement d'un accès à KVM. Les environnements de conteneurs et LVE ne sont pas vulnérables du simple fait qu'ils partagent le noyau de l'hôte. La vulnérabilité dépend de la capacité du conteneur à accéder à /dev/kvm, à contrôler QEMU ou à utiliser la virtualisation imbriquée. Nous n'avons pas testé ces environnements et ne les considérons pas comme sûrs par défaut. Vérifiez la configuration réelle des périphériques et des privilèges.

Versions des noyaux d'entreprise. Ne vous fiez pas uniquement à la commande « uname -r » pour déterminer si vous êtes concerné. Les distributions d'entreprise rétroportent les modifications apportées à KVM vers des versions de base plus anciennes ; ainsi, un noyau EL9 basé sur la version 5.14 contient la logique MMU affectée, tandis qu'un noyau numériquement plus récent peut déjà intégrer un rétroportage ciblant ce problème. Vérifiez le correctif fourni par le fournisseur, la couverture de KernelCare ou le modèle source pour identifier précisément le noyau en cours d'exécution.

Ici, le piège de la version fonctionne à l’inverse de ce qui se passe habituellement. Ce n’est pas « notre noyau est trop ancien », mais « notre matériel est trop récent ». Un hôte fonctionnant sous EPT ou NPT semble moderne et sûr jusqu’à ce qu’il expose une virtualisation imbriquée et redirige discrètement les machines invitées via un code shadow-MMU vieux de 16 ans. Il faut raisonner en fonction de ce que l’hôte expose, et non en fonction du silicium sur lequel il tourne.

Vérifier la surface d'attaque KVM

Vérifiez si les modules KVM sont chargés :

lsmod | grep -E '^kvm|kvm_(intel|amd)'

Vérifiez si le périphérique KVM existe et qui y a accès :

ls -l /dev/kvm

Vérifier la présence de charges de travail QEMU/KVM actives :

pgrep -a -f 'qemu-system|qemu-kvm'

Vérifiez si la virtualisation imbriquée est activée :

cat /sys/module/kvm_intel/parameters/nested   # Intel
cat /sys/module/kvm_amd/parameters/nested      # AMD

Pour les hôtes gérés par libvirt :

virsh list --all

Ces commandes vous indiquent si KVM est accessible, s'il est utilisé et s'il prend en charge la virtualisation imbriquée. Elles ne permettent toutefois pas de vérifier si Januscape a été corrigé.

Agir dès maintenant

Il existe ici de véritables mesures d'atténuation au niveau de la configuration, et chacune d'entre elles permet de colmater une faille spécifique. Aucune d'entre elles ne permet de toutes les colmater, et c'est justement là tout l'intérêt.

Hôtes qui n'exécutent pas de machines virtuelles. Si le système n'a pas besoin de KVM, déchargez les modules et empêchez leur chargement. Utilisez la commande `install … /bin/false` plutôt qu'une simple ligne dans la liste noire, car la liste noire à elle seule n'empêche pas un chargement explicite ou induit par des dépendances.

# unload now (fails if a VM is running, in which case this host isn't a candidate)
sudo modprobe -r kvm_intel kvm      # kvm_amd on AMD hardware

# prevent load on boot
printf 'install kvm_intel /bin/false\ninstall kvm_amd /bin/false\n' \
| sudo tee /etc/modprobe.d/disable-kvm.conf

Vérifiez que la commande « lsmod | grep kvm » ne renvoie aucun résultat et que la commande « ls /dev/kvm » indique qu'aucun fichier de ce nom n'existe. Pour annuler cette modification, supprimez le fichier /etc/modprobe.d/disable-kvm.conf et exécutez la commande « modprobe kvm_intel » (ou « kvm_amd »), ou redémarrez le système.

Les hôtes qui exécutent des machines virtuelles mais qui n'ont pas besoin de la virtualisation imbriquée. Il s'agit de la mesure de protection la plus efficace en l'absence de correctif. La désactivation de la virtualisation imbriquée supprime le chemin d'accès de l'invité vers l'hôte, car la MMU fantôme n'intervient que pour les invités imbriqués :

# Intel
echo 'options kvm_intel nested=0' | sudo tee /etc/modprobe.d/disable-nested-virt.conf
# AMD
echo 'options kvm_amd nested=0' | sudo tee /etc/modprobe.d/disable-nested-virt.conf

La modification prend effet après le rechargement du module KVM (ce qui nécessite qu'aucune machine virtuelle ne soit en cours d'exécution) ou après un redémarrage. Vérifiez que la commande `cat /sys/module/kvm_intel/parameters/nested` renvoie « N » ou « 0 ».

Les hôtes de la famille RHEL qui doivent héberger des machines virtuelles et des environnements virtuels imbriqués. Sur ces distributions, le répertoire /dev/kvm est accessible à tous (mode 0666), ce qui permet à un utilisateur local sans privilèges d'exploiter directement cette faille. Renforcez la sécurité :

echo 'KERNEL=="kvm", GROUP="kvm", MODE="0660"' \
| sudo tee /etc/udev/rules.d/65-kvm.rules
sudo udevadm control --reload-rules
sudo udevadm trigger --name-match=kvm

Vérifiez à l'aide des commandes `ls -l /dev/kvm` et `getent group kvm`, puis ajoutez uniquement les comptes qui ont besoin de KVM au groupe « kvm ». Cela permet de colmater la faille « unprivileged-local ». Cela n'empêche toutefois pas un invité malveillant d'accéder à la MMU fantôme via son processus QEMU autorisé, quelles que soient les autorisations accordées aux périphériques de l'hôte.

Moment décisif. Si un hôte n’héberge aucun invité, désinstallez et bloquez KVM. S’il héberge des invités qui n’ont pas besoin de virtualisation imbriquée, désactivez immédiatement cette fonctionnalité et appliquez les correctifs selon votre rythme habituel. S’il héberge des invités non fiables et a besoin de virtualisation imbriquée (cloud multi-locataires, hébergement, CI créant des machines virtuelles imbriquées), aucun changement de configuration ne vous protège entièrement ; privilégiez donc l’application d’un correctif sans redémarrage ou d’un noyau corrigé. Et considérez une reproduction ne générant qu’un avertissement comme une confirmation de la vulnérabilité, et non comme une preuve de sécurité.

Détection

Januscape ne laisse aucune signature fiable sur le disque. La corruption se produit dans la mémoire du noyau de l'hôte tandis que KVM gère les tables de pages fantômes et les mappages inversés ; ainsi, les outils de vérification de l'intégrité des fichiers peuvent rester intacts même après le déclenchement de l'état de vulnérabilité. Cela repousse la détection vers l'analyse comportementale, et chacun des éléments suivants constitue un indice, et non une preuve.

Erreurs ou avertissements du noyau dans le fichier arch/x86/kvm/mmu/mmu.c, notamment ceux liés à la fonction pte_list_remove().
Messages d'incompatibilité GFN, ou avertissements émis par la fonction `kvm_mmu_page_set_translation()` : la confusion entre les rôles et les trames devient visible avant la libération.
L'hôte entre en état de panique ou subit des plantages répétés lorsque qemu-kvm ou qemu-system-* est actif, sans qu'aucune défaillance matérielle ne soit à l'origine de ces problèmes.
Un noyau marqué « W » à la suite d'un avertissement de la MMU KVM.
Une activité de virtualisation imbriquée là où vous ne vous y attendiez pas, ou un accès à /dev/kvm par des comptes ou des processus inhabituels.
Un compte ou un service hôte local acquérant des privilèges peu après une période d'instabilité de la MMU KVM, sans qu'aucun événement « sudo » ou de connexion correspondant ne soit enregistré.

Consulter les messages récents du noyau :

journalctl -k --since "24 hours ago" \
| grep -Ei 'kvm|mmu|gfn|pte_list_remove|BUG|WARNING'

Vérifiez le démarrage actuel :

dmesg -T | grep -Ei 'kvm|mmu|gfn|pte_list_remove|BUG|WARNING'

L'absence de ces messages ne prouve pas que l'hôte ait été corrigé. Un attaquant peut éviter de déclencher le contrôle de cohérence, et il se peut tout simplement qu'une faille n'ait pas encore été exploitée. Si des machines invitées non fiables s'exécutent sur un hôte exposé et que vous constatez une instabilité de KVM-MMU, considérez que l'hôte mérite un examen plus approfondi (nouveaux comptes, configuration d'authentification modifiée, services inattendus sur l'hôte) plutôt que de considérer les hachages de fichiers sains des machines invitées comme la preuve que l'hôte fonctionne correctement.

Pourquoi Januscape est-il si important ?

Januscape relève d'une catégorie de problèmes distincte de celle des failles locales d'escalade de privilèges au niveau du noyau. Une faille LPE locale classique nécessite que l'attaquant dispose déjà d'un accès permettant l'exécution de code sur l'hôte. Une « évasion de l'invité » part d'un code que l'organisation a délibérément autorisé à s'exécuter au sein d'une machine virtuelle, en partant du principe que KVM le contiendrait. C'est précisément cette hypothèse qui est remise en cause.

C’est pourquoi cela touche particulièrement les environnements où l’isolation des utilisateurs est un élément essentiel : les clouds publics et privés, les fournisseurs d’hébergement, les clusters multi-locataires, les infrastructures d’intégration continue (CI) et de compilation, les environnements de recherche en sécurité, les clouds pour développeurs, ainsi que toute plateforme exécutant des machines virtuelles contrôlées par les clients. L’ancienneté de cette hypothèse sous-jacente aggrave encore la situation. Ce comportement remonte à 2010 et s’est perpétué à travers de nombreuses générations de noyaux d’entreprise ; ainsi, l’argument « nous utilisons une distribution moderne » ne constitue pas une défense valable.

La raison pour laquelle il est facile de se tromper est précisément celle pour laquelle cela est dangereux. Trois signaux plausibles indiquent tous que la situation est « sûre », mais tous induisent en erreur. Les modes EPT ou NPT au niveau matériel donnent l’impression d’avoir mis hors service la MMU fantôme, mais la virtualisation imbriquée ramène immédiatement les machines invitées en son sein. Le correctif GFN (CVE-2026-46113) donne l’impression d’avoir bouclé cette partie de la MMU, mais il n’a corrigé que la moitié du défaut et a laissé le cas de figure ouvert. Et un PoC qui ne fait planter qu’une machine qui vous appartient ressemble à un auto-DoS inoffensif, alors que ce plantage n’est qu’une démonstration publique et non la limite maximale. Si vous vous fiez à l’un d’entre eux, vous classerez un hôte vulnérable comme sûr.

Le lien avec la vulnérabilité CVE-2026-46113 est la principale source de fausse assurance. Une équipe ayant corrigé la vulnérabilité antérieure liée à une utilisation après libération inattendue de GFN pourrait en conclure que le problème de « shadow-paging » est résolu. Ce n'est pas le cas. Le correctif précédent vérifiait si KVM avait trouvé la bonne trame. Januscape a démontré que KVM devait également vérifier qu'il avait trouvé le bon type de page fantôme. Une seule correspondance ne suffisait pas, et la fermeture d'un CVE ne signifie pas que les deux problèmes sont résolus.

Liste de contrôle des mesures correctives prioritaires

Enregistrez ce problème sous la référence CVE-2026-53359 (Januscape), et non sous CVE-2026-46113.
Vérifiez que les serveurs concernés disposent à la fois du correctif Januscape et du correctif associé CVE-2026-46113. Ces deux correctifs sont obligatoires.
Répertorier les hôtes sur lesquels des modules KVM sont chargés, sur lesquels /dev/kvm est présent ou sur lesquels des charges de travail QEMU sont actives, et signaler ceux qui prennent en charge la virtualisation imbriquée.
Donnez la priorité aux hôtes multi-locataires et à tout hôte exécutant des machines invitées non fiables avec la virtualisation imbriquée activée.
Désactivez complètement KVM sur les hôtes qui n'utilisent pas la virtualisation.
Désactivez la virtualisation imbriquée lorsqu’elle n’est pas nécessaire : cela supprime la voie d’échappement pour les invités non fiables.
Limitez l'accès à /dev/kvm aux comptes de confiance et au groupe « kvm » sur les hôtes de la famille RHEL. Cela bloque uniquement le vecteur d'attaque local sans privilèges, et non un invité malveillant.
Vérifiez explicitement les serveurs AMD : ils sont affectés même lorsque les tests effectués uniquement sur des processeurs Intel n'ont révélé aucun problème.
Ne tirez pas de conclusions quant à la sécurité en vous basant uniquement sur la version du noyau, et considérez toute reproduction ne donnant lieu qu'à un avertissement comme une exposition.
Recherchez les avertissements KVM GFN, les échecs de la fonction pte_list_remove() et les pannes inexpliquées de l'hôte, et considérez que des hachages de fichiers invités intacts ne constituent pas une preuve suffisante concernant l'hôte.
Appliquez un noyau fourni par le fournisseur et redémarrez le système, ou utilisez le correctif « sans redémarrage » de KernelCare pour le noyau actuellement en cours d'exécution, en donnant la priorité aux hôtes les plus difficiles à redémarrer.
Vérifiez que les deux correctifs couvrent explicitement les vulnérabilités CVE, plutôt que de vous fier aux dates de compilation.

Patching sans redémarrage

Januscape est le genre de faille d’hyperviseur qui reste exposée longtemps après la mise à disposition d’un paquet corrigé. L’installation du paquet n’est qu’une première étape. L’hôte doit encore démarrer avec le noyau de remplacement, ce qui, sur un cluster KVM, implique de vider les nœuds, de migrer les machines virtuelles, de coordonner les locataires, de maintenir des marges de capacité et de faire tourner les machines pendant la maintenance. Ces contraintes peuvent prolonger une fuite connue d’une machine virtuelle pendant des semaines, voire des mois, et elles pèsent le plus lourdement sur les hôtes multi-locataires, qui sont justement les plus exposés au risque.

Cette modification est un bon candidat pour un correctif sans redémarrage : il s’agit d’une petite correction concernant la faille MMU et le chemin de mappage inverse, sans état persistant à transférer. KernelCare intègre les deux correctifs requis – celui concernant le rôle Januscape (81ccda30b4e8) et le correctif GFN associé (0cb2af2ea66a) – dans le noyau en cours d’exécution, avec des variantes par famille de noyaux pour les lignes de rétroportage EL 5.14 et les noyaux 6.x basés sur la branche principale. LibCare ne s’applique pas, car il s’agit d’un bogue propre au noyau, sans composante de bibliothèque dans l’espace utilisateur.

État de la version au 29 juillet 2026.

KernelCare fournit conjointement le correctif pour le rôle Januscape et le correctif associé requis pour le CVE-2026-46113 ; la disponibilité est donc indiquée par famille de noyaux plutôt que par CVE.

Stable, entièrement mis en avant

RHEL 10 – ensemble de correctifs K20260703_15

Oracle Linux 10 – K20260703_16

Rocky Linux 10 – K20260703_17

AlmaLinux 10 – K20260703_18

Debian 13 – K20260706_09

Ubuntu 22.04 – K20260706_01 (_02 pour arm64, _03 pour Azure, _04 pour AWS)

Ubuntu 20.04 avec le noyau Jammy HWE – K20260706_06 (Azure : _05, AWS : _07)

Ubuntu 24.04 – K20260707_01 (AWS : _02)

Proxmox VE 7 (5.15) – K20260706_08

Proxmox VE 8 (6.8) – K20260707_03

Enterprise Linux 9, sorti en juillet 2026

RHEL 9 – K20260710_58

AlmaLinux 9 et CloudLinux 9 – K20260710_60

Oracle Linux 9 – K20260710_63

Rocky Linux 9 – K20260710_65

Déploiement par étapes

Debian 12 – K20260709_25

Debian 11 – K20260710_11

Noyau standard d'Ubuntu 20.04 – K20260710_10

CloudLinux 8 – K20260709_27

En phase de test

RHEL 8 – K20260710_31

AlmaLinux 8 – K20260710_41

Rocky Linux 8 – K20260710_43

CentOS 8 – K20260710_33

Oracle Linux 8 – K20260710_35

CloudLinux 7 hybride – K20260710_39

Toujours ouvert

Oracle UEK6, Oracle UEK7, Amazon Linux 2, Ubuntu 18.04.

Enterprise Linux 7 est concerné, mais aucun correctif n'est prévu pour le moment. L'impact concret se limite à un déni de service : une attaque DoS d'un locataire vers l'hôte est irréalisable, car le VMX imbriqué est suffisamment lent pour rendre la condition de concurrence peu fiable, et la voie d'élévation locale des privilèges est bloquée par CONFIG_BUG_ON_DATA_CORRUPTION. Les hôtes sous EL7 doivent tout de même appliquer les mesures d'atténuation de configuration mentionnées ci-dessus.

La prise en charge d’Enterprise Linux 9 est désormais disponible pour RHEL 9, AlmaLinux 9, CloudLinux 9, Oracle Linux 9 et Rocky Linux 9. Cela revêt une importance particulière, car c’est sur une plateforme EL9 qu’un « host panic » fatal s’est produit dans notre laboratoire ; les hôtes EL9 exposés restent donc les premiers à corriger, mais ils n’ont plus besoin de se contenter de mesures d’atténuation par la configuration en attendant la disponibilité d’un correctif. Les plateformes non encore couvertes sont Oracle UEK6 et UEK7, Amazon Linux 2 et Ubuntu 18.04 ; ces hôtes dépendent toujours des mesures d'atténuation mentionnées ci-dessus ou d'un noyau corrigé par le fournisseur.

Postuler à partir du flux de tests :

sudo kcarectl --update --prefix test

Appliquer à partir du flux de production une fois la mise à jour effectuée :

sudo kcarectl --update

Vérifiez la version du patch en cours d'exécution :

kcarectl --info | grep kpatch-build-time      # build dated 2026-07 or later

Étant donné que Januscape a besoin de ces deux correctifs, vérifiez bien qu’ils sont tous les deux présents plutôt que de vous fier à une date :

kcarectl --patch-info | grep -E

'CVE-2026-53359|CVE-2026-46113'

Deux résultats positifs constituent une réponse claire. Un résultat positif uniquement pour CVE-2026-46113 ne prouve pas, à lui seul, que le correctif de rôle est absent, en raison de l’historique d’étiquetage mentionné précédemment — dans ce cas, vérifiez le K-tag installé par rapport à la liste des versions ci-dessus, ou consultez l’enregistrement de couverture KernelCare pour cette famille de noyaux. La date de compilation, à elle seule, ne prouve rien. Un noyau compilé après la mi-juin n’intègre pas automatiquement ce correctif, et cela ne garantit pas que les deux correctifs soient présents. Vérifiez le mappage CVE, le K-tag, l’erratum du fournisseur ou directement le code source.

Januscape transforme un léger décalage entre les pages d'ombre KVM en une faille au niveau de la frontière entre l'invité et l'hôte. Pour les parcs de virtualisation qui ne peuvent pas supporter de redémarrages d'urgence, un correctif sans redémarrage comble cette faille dans le noyau en cours d'exécution sans vider chaque nœud ni interrompre ses invités.

Procurez-vous KernelCare dès aujourd’hui →