PwnEscape est resté caché dans la pile réseau du noyau pendant 18 ans

En bref

De quoi s'agit-il ? La vulnérabilité CVE-2026-99999, que le chercheur a baptisée « PwnEscape », est une faille liée à la manière dont le noyau Linux calcule les sommes de contrôle IPv4 pour les paquets accompagnés de métadonnées de déchargement. Une machine virtuelle invitée peut fournir des métadonnées de déchargement de somme de contrôle qui poussent l'hôte à écrire deux octets dans un en-tête IPv4 que le noyau a déjà validé. Le CNA du noyau a publié cette vulnérabilité le 15 octobre 2026.

Impact : la mémoire de l'hôte fuit dans les paquets envoyés par l'invité, et Vercel précise que cette faille a été démontrée sur ses environnements de test en production. Le chercheur a également provoqué le plantage d'hôtes et exécuté du code sur ceux-ci en tant qu'administrateur, mais uniquement sur ses propres machines KVM et Firecracker, configurées pour reproduire l'environnement de Vercel.

Gravité : Le noyau CNA lui attribue une note de 9,3 (critique) selon le CVSS 3.1, avec un vecteur d'attaque local et une portée modifiée. Sur un hôte multi-locataires, cependant, le terme « local » peut désigner une machine virtuelle louée par l'un de vos clients, et les dommages se répercutent sur l'hôte sous-jacent.

Qui est concerné : le code vulnérable remonte à la version 2.6.27 de Linux, sortie en 2008. Les noyaux Enterprise Linux, de la version EL7 à la version EL10, devraient être concernés, notamment RHEL, AlmaLinux, Rocky Linux, Oracle Linux et CloudLinux, bien que les arborescences de noyau individuelles n’aient pas encore été vérifiées. Les hôtes exécutant des machines virtuelles qu’ils ne contrôlent pas sont les premiers concernés, ainsi que les serveurs partagés sur lesquels des utilisateurs non fiables disposent d’un shell. Sur les versions EL8 à EL10, le répertoire /dev/kvm est accessible en écriture à tous par défaut ; ces utilisateurs pourraient donc démarrer leur propre machine virtuelle et l’utiliser pour attaquer l’hôte.

Statut : le correctif a été intégré à la branche principale le 14 octobre, et sept noyaux stables en amont l’ont intégré le 15 octobre. Au 16 octobre, aucun noyau de distribution n’avait encore intégré ce correctif. Il n’existe aucun code d’exploitation public et aucun cas d’exploitation en milieu réel n’a été signalé. Il s’agit d’une divulgation coordonnée, et non d’une faille « zero-day ».

Procédez ainsi dès maintenant : sur les hôtes exécutant des machines virtuelles non fiables, désactivez le déchargement des sommes de contrôle sur les interfaces virtio-net de ces machines virtuelles et acceptez la perte de débit qui en résulte. Ce paramètre n’a aucun effet sur une machine virtuelle lancée par un utilisateur local pour son usage personnel ; par conséquent, sur les hôtes hébergeant des utilisateurs de shell non fiables, désactivez également les espaces de noms des utilisateurs non privilégiés. Si vous compilez vos propres noyaux, passez à une version stable en amont définitive.

Sur un hôte libvirt, vérifiez la définition d'une machine invitée pour voir si elle contient des paramètres explicites relatifs aux sommes de contrôle :

virsh dumpxml <domain> | grep ‘csum=’

Ces attributs n'apparaissent dans le fichier XML que lorsqu'ils ont été définis. Pour une interface virtio, une sortie vide signifie que les paramètres par défaut de QEMU sont actifs, et ces paramètres laissent la décharge de la somme de contrôle activée.

La version longue

L'hébergement de machines virtuelles multi-locataires repose sur une promesse : tout ce qu'un client exécute au sein de sa machine virtuelle reste confiné à l'intérieur de celle-ci. PwnEscape rompt cette promesse grâce à une écriture de deux octets que le noyau hôte effectue sur lui-même.

Ce qui rend celui-ci particulier, c'est l'endroit où il se trouve. Il n'est pas dans KVM et, contrairement à Januscape et Zapscape en début d'année, il ne nécessite pas de virtualisation imbriquée. Le bogue se trouve dans le chemin de sortie IPv4 standard de l'hôte. Une machine invitée y accède de la même manière qu'elle le fait des milliers de fois par seconde, en demandant à l'hôte de calculer une somme de contrôle à sa place.

Le correctif a été intégré en amont, mais les noyaux des distributions ne l'ont pas encore intégré, alors qu'un rapport détaillé a été publié en même temps que le CVE. Tant que ces deux éléments ne seront pas synchronisés, les serveurs resteront exposés.

Ce qui s'est réellement passé cette semaine

Paulos Yibelo, de pwn.ai, a découvert cette faille lors de la troisième journée du défi « Vercel Sandbox $1M ». Il en a signalé la cause première en privé aux responsables de la sécurité du noyau et aux responsables de la maintenance du réseau le 4 septembre, et Michael S. Tsirkin, de Red Hat, a réussi à la reproduire trois jours plus tard.

La série de correctifs a été rendue publique sur netdev le 19 septembre. Le correctif plus ciblé de Tsirkin, le commit 6785011f8b16, a été appliqué à l’arborescence « networking » le 8 octobre et intégré à la branche principale le 14 octobre, le jour même où Vercel a publié les résultats de son défi. Le CVE, sept noyaux stables et l'article du chercheur, intitulé « PwnEscape : Guest-to-Host KVM Escape », ont tous été publiés le 15 octobre. Cet article explique le bug en détail mais ne fournit aucun code d'exploitation.

Comment deux octets peuvent entraîner une fuite de mémoire sur l'hôte

Les paquets arrivant via TAP, vhost-net ou AF_PACKET peuvent contenir un virtio_net_hdr, un petit bloc d'indications de déchargement fournies par l'expéditeur. Deux de ces indications, csum_start et csum_offset, indiquent au noyau où commence la zone de somme de contrôle et où stocker le résultat ; le paquet est alors marqué CHECKSUM_PARTIAL afin qu'un composant en aval puisse terminer le traitement.

Le point faible réside dans la vérification des données d'entrée. La fonction `virtio_net_hdr_to_skb()` vérifie uniquement que `csum_start` se trouve à au moins 20 octets dans le tampon. Sur TAP, ce tampon commence par l'en-tête Ethernet de 14 octets ; ainsi, 20 octets se trouvent exactement à l'intérieur de l'en-tête IPv4. Aucune vérification ne compare `csum_start` à la fin de l'en-tête IP.

Lorsque l'hôte doit fragmenter le paquet, la fonction `ip_do_fragment()` appelle `skb_checksum_help()`, qui calcule la somme de contrôle et écrit deux octets à l'adresse `csum_start + csum_offset`. C'est l'invité qui fournit les données faisant l'objet de la somme de contrôle ; il contrôle donc effectivement ces deux octets. L'écriture ne quitte jamais le tampon de paquets. Elle aboutit dans un en-tête IP que le noyau a déjà analysé, acheminé et jugé fiable.

Le fragmentateur relit ensuite cet en-tête. Dans le cas du chercheur, le premier octet est passé de 0x45 à 0x4f, toujours en IPv4, mais le champ de longueur d’en-tête (ihl) indiquait désormais 60 octets au lieu de 20. La fonction `ip_frag_next()` copie ce nombre d’octets d’en-tête dans chaque fragment. Les données linéaires valides du paquet ne représentaient que 28 octets (20 d’en-tête et 8 de charge utile) ; les 32 derniers octets de chaque copie provenaient donc de la mémoire de l’hôte, au-delà de la fin du paquet. Ils quittent l’hôte sous forme d’options IPv4 dans les fragments transmis, où tout récepteur contrôlé par l’attaquant peut les lire.

Trente-deux octets, ce n’est pas grand-chose, mais la fuite se répète tant que l’invité continue d’envoyer des données. Le chercheur a combiné cette technique avec le « heap grooming » pour insérer des écritures ciblées de 64 octets dans la mémoire du noyau de l’hôte, puis a exécuté un programme auxiliaire sur l’hôte en tant qu’administrateur, lors de quatre démarrages à froid distincts en laboratoire. Cette chaîne d’exploitation n’est pas publique, et TuxCare n’a pas réussi à la reproduire.

Interprétation de la note de 9,3

Le vecteur est AV:L/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:H, et c'est la partie AV:L qui pose problème.

C'est la modification de la portée qui importe. L'attaquant se trouve dans un domaine de sécurité, celui de l'invité, tandis que les dégâts se produisent dans un autre, celui de l'hôte. C'est précisément la situation que la portée CVSS est censée refléter, et c'est pourquoi une faille locale obtient un score de 9,3. Le NVD n'avait pas publié sa propre analyse au moment de la rédaction de cet article ; le score CNA est donc le seul disponible.

Au moins une base de données de vulnérabilités la répertorie déjà comme exploitable à distance. En soi, ce n'est pas le cas. CHECKSUM_PARTIAL et csum_start sont des métadonnées relatives au tampon de paquets du noyau, et non des octets contenus dans le paquet. Les cartes réseau ne les définissent jamais à partir des données reçues. GRO peut les définir, mais uniquement à partir d'un en-tête TCP que le noyau a lui-même analysé, et uniquement pour les paquets IPv4 sans options IP. Un paquet spécialement conçu provenant d’Internet ne peut pas y accéder.

Un attaquant distant doit d'abord se procurer un point d'ancrage, que ce soit dans une machine virtuelle, un conteneur ou un compte local. Sur un hôte de machines virtuelles multi-locataires, ce point d'ancrage s'obtient en payant avec une carte bancaire.

Qui peut atteindre le bug ?

Le scénario principal consiste en une machine virtuelle invitée non fiable accédant à l'hôte via TAP ou vhost-net, comme démontré à la fois sur des configurations KVM et Firecracker. La machine invitée n'a pas besoin d'accéder aux périphériques de l'hôte, car le gestionnaire de machines virtuelles (VMM) détient déjà le descripteur de fichier TAP et transmet les métadonnées de déchargement telles quelles.

Les cas locaux sont moins évidents. Au sein d’un espace de noms utilisateur, un processus non privilégié peut être en mesure d’ouvrir un périphérique « tun » avec IFF_VNET_HDR, car « tun » vérifie la capacité CAP_NET_ADMIN uniquement au sein de cet espace de noms, où le processus en dispose. Le périphérique « AF_PACKET » avec PACKET_VNET_HDR constitue un cas similaire, puisqu’il nécessite la capacité CAP_NET_RAW, qu’un espace de noms utilisateur accorde également. Aucun de ces deux cas n’a pu être reproduit. Les espaces de noms utilisateur non privilégiés, activés par défaut sur EL8 et les versions ultérieures, constituent le principal facteur de vulnérabilité ici, mais pas le seul. L’accès à un périphérique `macvtap` ou `ipvtap` existant constitue une voie distincte, avec ses propres exigences en matière d’autorisations. Il en va de même pour une machine virtuelle que l’utilisateur démarre pour lui-même. Sur EL8 à EL10, les règles udev par défaut laissent /dev/kvm accessible en écriture à tous, de sorte que n’importe quel utilisateur local peut en démarrer une et y disposer des droits root. Si cette machine virtuelle se voit attribuer un backend TAP ou vhost-net, généralement via un espace de noms utilisateur, elle peut transmettre à l’hôte les mêmes métadonnées de déchargement spécialement conçues qu’un invité client le ferait. Les serveurs d’hébergement mutualisé sont concernés, même s’ils n’exécutent jamais de machine virtuelle client.

Les environnements CI partagés qui compilent le code des clients dans des conteneurs sans accès root méritent donc qu'on s'y intéresse, même si le chemin d'accès local doit encore faire l'objet de tests.

Les hôtes exécutant des machines virtuelles que vous ne contrôlez pas et les serveurs partagés offrant un shell à des utilisateurs non fiables sont prioritaires, suivis des autres systèmes exécutant du code non fiable. Tous les autres systèmes présentent un niveau d'exposition connu plus faible et devraient tout de même bénéficier du correctif via le processus habituel de mise à jour de sécurité, en fonction de leur niveau de risque réel.

PwnEscape est-il une faille « zero-day » ?

Dans son article, Vercel parle d’une faille « zero-day » du noyau Linux, et lorsque Yibelo l’a découverte en août, personne en amont n’était au courant de son existence. Cependant, au moment de la publication du CVE-2026-99999, le correctif était déjà intégré à la branche principale. Pour ceux qui réagissent aujourd’hui, il s’agit d’une divulgation coordonnée avec un correctif disponible, sans code d’exploitation public et sans signalement d’utilisation en dehors du cadre de la recherche autorisée.

Le chercheur prévoit l'apparition, d'ici quelques semaines, d'exploits ciblant les configurations d'hyperviseurs les plus vulnérables, et d'ici moins d'un mois, celles par défaut. Considérez cela comme une prévision de sa part. Les hôtes exposés ne devraient pas attendre de voir si cette prévision se confirme.

Qui est concerné ?

État du noyau du fournisseur au 16 octobre 2026, distinct de l'état des correctifs sans redémarrage de KernelCare :

Ne vous fiez pas à la version de la distribution indiquée par la commande « uname -r ». Les noyaux d'entreprise intègrent des correctifs sans modifier leur version de base ; ainsi, un noyau EL dont la version semble antérieure à 5.10.272 ne prouve rien, ni dans un sens ni dans l'autre. Seul un avis du fournisseur ou un correctif vérifié, applicable sans redémarrage, pour ce noyau précis permet de trancher la question.

Procurez-vous KernelCare dès aujourd’hui →

Désactivation des prérequis jusqu’à ce qu’un correctif soit disponible

Chacune des options ci-dessous supprime un prérequis. Aucune n'a encore été testée par TuxCare ; essayez-les donc d'abord sur un invité non critique.

Ce qui importe pour les hôtes de machines virtuelles, c'est de ne pas proposer le déchargement des sommes de contrôle aux machines invitées auxquelles vous ne faites pas confiance. Avec QEMU directement, configurez-le au niveau du périphérique :

- périphérique virtio-net-pci, netdev=n0, csum=off, guest_csum=off

With libvirt, add <driver><host csum=’off’/><guest csum=’off’/></driver> inside the guest’s <interface> element. Either way it’s per VM, needs a full guest restart, and costs throughput because the guest loses TSO and GSO. Firecracker is the awkward case. It was one of the demonstrated targets, and whether offload can be switched off per VM there hasn’t been verified yet.

Pour le chemin local uniquement, désactivez les espaces de noms utilisateur sans privilèges. Notez d'abord la valeur actuelle à l'aide de la commande `sysctl user.max_user_namespaces`, puis exécutez :

sysctl -w user.max_user_namespaces=0

Cela bloque la création de nouveaux espaces de noms d’utilisateurs, mais ne touche pas à ceux qui existent déjà. Pour que cette configuration soit permanente, enregistrez-la dans un fichier situé dans le répertoire /etc/sysctl.d/ ; pour revenir en arrière, supprimez ce fichier et rétablissez l’ancienne valeur. Cette option a un coût réel : elle rend inopérants les conteneurs « rootless », ainsi que les sandbox de Chrome et de Flatpak, et n’a aucun effet sur la voie d’échappement de l’invité. Si seules des comptes de confiance doivent exécuter des machines virtuelles, une règle udev attribuant à /dev/kvm les droits 0660 pour le groupe kvm bloque également l’accès via la machine virtuelle elle-même, mais pas l’accès direct via tun.

Appliquer le correctif et vérifier le noyau en cours d'exécution

Si vous compilez vos propres noyaux, optez pour l'une des versions stables corrigées figurant dans le tableau. L'installation d'une de ces versions n'entraîne aucun changement tant que l'hôte n'a pas démarré avec celle-ci ; vérifiez donc quelle version est effectivement en cours d'exécution :

uname -r

Un serveur sur lequel le nouveau noyau a été installé sans que l'on ait jamais redémarré le système continue d'utiliser la version vulnérable, et les hyperviseurs sont les plus concernés par ce problème.

Une fois disponible pour votre noyau, le correctif KernelCare sans redémarrage permet d’appliquer la correction sans redémarrer le système. Lorsque les mises à jour automatiques sont activées, il est installé dès qu’il est disponible dans le flux du noyau en cours d’exécution, et la commande `kcarectl –update` le récupère à la demande. Pour vérifier la couverture :

kcarectl –patch-info | grep « CVE-2026-99999 »

Les correctifs ne nécessitant pas de redémarrage sont désormais en production pour la plupart des flux (voir l'état ci-dessus) ; ainsi, une fois que le vôtre aura été appliqué, la commande devrait afficher le CVE du noyau en cours d'exécution. En attendant, veillez à maintenir les mesures d'atténuation en place.

Vient ensuite le suivi. Le correctif en amont est mineur : 44 lignes ajoutées et 12 supprimées dans six fichiers. Il ajoute une fonction d’aide, ip_check_csum_start(), qui rejette les paquets dont le csum_start pointe avant la fin de l’en-tête IP, et l’appelle avant la fin du calcul de la somme de contrôle à cinq endroits : la fragmentation IP, la fragmentation conntrack du pont, nfnetlink_queue, xt_CHECKSUM et la sortie xfrm. Le message de validation qualifie cette modification de mesure de « défense en profondeur » et indique qu’« une validation plus complète à l’entrée est à venir ». Il faut donc s’attendre à une deuxième correction en amont, et peut-être à un deuxième correctif ne nécessitant pas de redémarrage. Ne fermez pas le ticket concernant la première correction.

Pourquoi PwnEscape est-il si important ?

La limite de l'invité va bien au-delà de l'hyperviseur. Tout élément de code de l'hôte qui se fie à ce que l'invité déclare au sujet de ses propres paquets s'appuie sur cette limite. Les métadonnées de déchargement existent pour des raisons de rapidité, et pendant 18 ans, le noyau s'est fié aux indications de l'invité pour déterminer où placer une somme de contrôle.

Si vous exécutez des machines virtuelles appartenant à d'autres utilisateurs, désactivez dès maintenant le déchargement des sommes de contrôle sur les invités non fiables. Si vous accordez un shell à d'autres utilisateurs, désactivez les espaces de noms des utilisateurs non privilégiés. Dans tous les cas, appliquez le correctif au noyau en cours d'exécution dès qu'il sera disponible pour votre branche. Continuez ensuite à suivre l'évolution en amont, car d'autres mesures de validation des entrées sont en cours de développement. Lorsque le redémarrage d'un hyperviseur implique d'évacuer au préalable les machines invitées, le correctif « rebootless » de KernelCare est conçu pour corriger le bogue dans le noyau en cours d'exécution dès sa publication pour votre version de noyau, sans nécessiter d'évacuation ni de fenêtre de maintenance.

Procurez-vous KernelCare dès aujourd’hui →

Chronologie

Références

Les sources principales de cet article sont la fiche CVE-2026-99999 publiée par le CNA du noyau le 15 octobre 2026, les conclusions de Vercel issues du défi « Vercel Sandbox » doté d’un million de dollars (14 octobre 2026), ainsi que le rapport du chercheur intitulé « PwnEscape : Guest-to-Host KVM Escape (15 octobre 2026), le rapport de correctif du chercheur sur netdev, le correctif en amont 6785011f8b16, l’annonce de LWN concernant les sept versions stables, ainsi que l’entrée correspondante dans le suivi de sécurité de Debian.