Modèles

Vulnérabilité Vghost dans le noyau Linux : élévation de privilèges locale et fuite de machine virtuelle

17 octobre 2026 · 5 min de lecture

laptop on white table
Dell / Unsplash

Une faille dans le sous-système vhost du noyau Linux permet à un utilisateur local de lire et d'écrire dans la mémoire kernel à volonté et de devenir root sur près d'une décennie de versions du noyau. Dans une configuration de virtualisation, elle permet à une machine virtuelle non fiable d'écrire dans la mémoire de l'hôte et de pirater le programme qui exécute la machine virtuelle.

Le bug est suivi sous l'identifiant CVE-2026-74580 et nommé Vghost. Le laboratoire Zhuque de Tencent, qui a découvert la faille, a publié un correctif le 3 août et une analyse complète le 12 octobre avec des démonstrations fonctionnelles des deux attaques. Il n'existe à ce jour aucun signe public d'exploitation.

Vhost est la partie du noyau Linux qui accélère les entrées/sorties réseau et autres pour les machines virtuelles et les conteneurs. Un utilisateur local y accède en ouvrant un nœud de périphérique, généralement /dev/vhost-net ou /dev/vhost-vsock.

Sur l'hôte, la faille donne à un utilisateur non privilégié un moyen fiable de lire et d'écrire n'importe quelle adresse kernel, de contourner KASLR et d'escalader les privilèges vers root. L'attaque est déterministe : elle ne nécessite ni élagage de mémoire ni chance de temporisation.

La seconde attaque est plus ciblée. Lorsque le dispositif virtio d'une machine virtuelle se trouve derrière une IOMMU virtuelle avec iommu_platform activé, et que vhost s'exécute en mode device-IOTLB, une machine invitée non fiable peut déclencher le même bug et forcer le kernel de l'hôte à écrire hors limites dans le processus QEMU de l'hôte. À partir de là, une machine invitée peut remplacer une fonction QEMU et prendre le contrôle de l'endroit où le processus hôte s'exécute ensuite, ou le faire planter.

Vhost conserve un petit cache des mémoires derrière chaque anneau virtuel et les files d'attente partagées utilisées pour déplacer les données. Un coup de cache est traité comme preuve que la région était déjà vérifiée. Le cache est vidé lorsque la mémorisation est mise à jour ou invalidée et lorsque la file d'attente est réinitialisée, mais pas lorsque les commandes VHOST_SET_VRING_ADDR ou VHOST_SET_VRING_NUM modifient les adresses ou la taille de l'anneau alors que la file est active.

Avec une IOTLB attachée, ces commandes acceptent les nouvelles adresses sans les vérifier, laissant cette vérification pour plus tard. Une fois le cache rempli, la vérification ultérieure ne s'exécute plus, et vhost continue de traduire de nouvelles adresses en utilisant l'ancienne mémorisation. Le kernel copie ensuite des données vers ou depuis ce pointeur sans vérification de borne, donc une écriture dans l'anneau utilisé ou une lecture d'un descripteur atterrit en dehors de la région mémorisée. Cela donne à l'attaquant un accès kernel en lecture et en écriture.

La faille était présente dans le code depuis environ neuf ans car elle a fallu deux modifications raisonnables pour la créer. Un changement en 2017 (Linux 4.11) a ajouté le cache et son raccourci. Un changement en 2020 (Linux 5.9) a déplacé la vérification d'adresse hors de la commande et vers une étape ultérieure, supprimant la vérification qui aurait autrement attrapé la traduction stale.

Qui est affecté et que faire

La faille affecte les kernels Linux de 4.11 à 7.2-rc4. Tencent a reproduit la chaîne complète d'utilisateur local à root sur cinq distributions de noyaux : Ubuntu 26.04, RHEL 9.8, Amazon Linux 2023, Microsoft Azure Linux 3.0 et Oracle Linux 10.2. Sur Ubuntu, le nœud de périphérique était limité au groupe KVM, donc le point de départ y était un membre de ce groupe plutôt que n'importe quel utilisateur.

Sur les quatre autres images testées, le nœud était accessible en lecture/écriture pour tous (mode 0666), donc n'importe quel utilisateur local pouvait y accéder.

Le correctif (commit de845981da67) vide le cache à chaque reconfiguration de l'anneau. Installez un kernel qui le contient et redémarrez. Les premières versions stables corrigées en amont sont répertoriées ci-dessous ; les fournisseurs peuvent également backporter le correctif sans changer leur numéro de version.

Red Hat, Amazon Linux et Oracle Linux ont expédié des correctifs. Ubuntu a corrigé la 22.04 et, au 13 octobre, indique toujours que ses kernels 24.04 et 26.04 sont en cours de correction.

Jusqu'à ce qu'un kernel corrigé soit en place, restreignez l'accès aux nœuds de périphériques vhost. Retirez l'accès monde à /dev/vhost-net et /dev/vhost-vsock, limitez le groupe propriétaire aux services de virtualisation de confiance, et traitez l'appartenance à ce groupe comme un privilège pendant que le kernel vulnérable tourne.

Il n'existe pas de contournement intermédiaire pour la fuite machine invitée vers hôte ; pour ce chemin, le kernel corrigé est le seul remède.

Sévérité et finder IA

La faille est notée élevée, pas critique, et les évaluateurs divergent sur la hauteur. L'équipe CVE de kernel.org lui attribue 8.8 et marque son étendue comme modifiée, car l'écriture vers l'hôte atteint une mémoire dans le processus QEMU de l'hôte et franchit la frontière entre une machine invitée et son hôte.

Red Hat la note 7.3 et marque l'étendue comme inchangée, traitant l'impact comme restant dans la frontière de confiance propre de l'hôte ; elle note également l'impact d'intégrité plus bas. Amazon l'a notée 7.8 et Oracle 7.3.

Le bug a été trouvé avec l'aide de Corvus AI, un système multi-agents que Tencent a construit pour la recherche de vulnérabilités kernel. Le crédit upstream lui attribue une ligne Assisted-by, et Tencent affirme que le pipeline a découvert la faille.

C'est de la recherche assistée par machine, pas une attaque menée par IA. C'est la même équipe et le même pipeline derrière une faille kernel SCTP de 18 ans divulguée en août, qui a également atteint root et, dans les tests, échappé un conteneur.