PwnEscape : une faille IPv4 de Linux accessible depuis une VM KVM

CVE-2026-99999, que le chercheur Paulos Yibelo appelle PwnEscape, est une faille du traitement réseau IPv4 du noyau Linux, accessible par certains chemins entre une machine virtuelle et son hôte. Le défaut se trouve dans le noyau de l’hôte, pas dans le code de KVM. Il peut notamment entraîner une divulgation de mémoire, tandis que l’exécution avec les privilèges root a été rapportée séparément dans un environnement de recherche contrôlé.

Pour les personnes qui administrent des hôtes de virtualisation, le point clé est de corriger le noyau de l’hôte concerné : mettre à jour seulement le système invité ne corrige pas le chemin vulnérable.

Où se trouve la faille

PwnEscape touche le traitement des paquets IPv4 dans le noyau Linux. KVM, avec virtio-net et TAP, peut fournir un chemin par lequel des données contrôlées depuis un invité atteignent ce code. La faille n’est donc pas dans le noyau propre à la machine virtuelle ni dans le code de KVM lui-même. Le correctif intégré au noyau Linux intervient dans le traitement IPv4.

Le point de départ est du code exécuté dans un invité. AWS décrit, pour le scénario couvert par son bulletin, un accès privilégié à l’intérieur de cet invité. Cela ne signifie pas que l’attaquant dispose déjà de privilèges root sur l’hôte.

Comment les métadonnées de somme de contrôle exposent de la mémoire

Les paquets peuvent transporter des métadonnées qui indiquent au noyau où commencer une opération différée de somme de contrôle. Dans le scénario technique décrit par Yibelo, ces données modifient un en-tête IPv4 après son traitement initial. La fragmentation du paquet se fie ensuite à la nouvelle longueur indiquée par l’en-tête.

Dans son cas contrôlé, l’interprétation de l’en-tête est passée de 20 à 60 octets. Le paquet ne contenait que 28 octets de données linéaires logiques : 20 octets d’en-tête IPv4 et 8 octets de charge utile. La différence a permis de divulguer 32 octets de mémoire de l’hôte dans les fragments transmis. Yibelo décrit cette divulgation comme répétable dans le cas étudié ; le résultat dépend de ce scénario précis. Son compte rendu technique détaille la géométrie du paquet.

Divulgation de mémoire et exécution root : deux résultats distincts

Yibelo rapporte une divulgation de 32 octets dans le contexte des sandbox de production de Vercel. Il décrit séparément des écritures ciblées de 64 octets dans le noyau et l’exécution d’un programme auxiliaire avec les privilèges root sur l’hôte. Cette seconde chaîne a fonctionné sur quatre démarrages à froid dans son propre environnement KVM de recherche.

La divulgation de mémoire et la chaîne d’exécution root sont donc deux résultats distincts, obtenus dans des contextes différents. Yibelo ne rapporte pas d’exécution root sur un hôte de production d’un fournisseur.

Ce que change le correctif upstream

Le correctif ajoute ip_check_csum_start(), une vérification qui rejette un début de somme de contrôle situé avant la fin de l’en-tête IPv4. Le noyau effectue ce contrôle avant de terminer la somme de contrôle dans cinq points de traitement. Yibelo décrit cette modification comme une défense en profondeur. Le commit Linux montre les vérifications ajoutées.

Pour les systèmes virtualisés, l’intervention concerne le noyau de l’hôte : c’est lui qui exécute le code réseau vulnérable. Les versions de paquets peuvent varier selon le fournisseur, car les distributions peuvent intégrer les correctifs à leurs propres noyaux.

Services AWS gérés et hôtes administrés par les clients

Dans son bulletin du 15 octobre 2026, AWS distingue ses services gérés des hôtes KVM que ses clients administrent eux-mêmes. AWS indique que ses services EC2, Lambda et Fargate gérés ne sont pas concernés. Les hôtes KVM/virtio-net autogérés qui utilisent un noyau vulnérable non corrigé sont, eux, dans le périmètre décrit par le bulletin. AWS recommande de mettre à jour le noyau de l’hôte concerné et de le redémarrer.

Cette distinction porte sur les services AWS nommés et sur les hôtes que les clients administrent eux-mêmes. Elle ne s’étend pas automatiquement à d’autres offres cloud.

Pourquoi deux scores CVSS sont publiés

Les valeurs publiées correspondent à deux évaluations CVSS 3.1 et à des métriques différentes pour les privilèges requis. L’avis de Red Hat indique un score de 9,3 pour cve.org, avec PR:N, et une évaluation produit de Red Hat à 8,8, avec PR:L. L’avis de Red Hat présente ces deux évaluations.