La faille de fragmentation IPv6 qui compromet l'isolation des conteneurs sur EL10

En bref

Quoi : Une faille permettant l'escalade de privilèges en local sous Linux et l'évasion du conteneur, surnommée « ipv6-frag-escape ». Une erreur arithmétique dans le chemin de sortie des paquets IPv6 (__ip6_append_data()) sous-estime la taille de la tête linéaire d'un tampon de socket de fraggap octets ; ainsi, une copie effectuée ultérieurement provoque un débordement dans le skb_shared_info à la fin de cette même allocation. Ce débordement de tas au sein d’un bloc mémoire suffit à transformer un processus sans privilèges, exécuté dans un conteneur, en utilisateur root sur l’hôte. Aucun identifiant CVE n’avait encore été attribué au moment de la publication.

Impact : une démonstration publique de sgkdev (github.com/sgkdev/ipv6_frag_escape) permet d’obtenir un shell root interactif dans les espaces de noms initiaux et le système de fichiers racine de l’hôte, à partir d’un processus sans privilèges exécuté dans un conteneur isolé du réseau. Le fichier README répertorie les cibles testées, notamment CentOS Stream 10 sur la version 6.12.0-242.el10 et RHEL 10 sur la version 6.12.0-228.el10. KernelCare a reproduit en interne l’accès root à l’hôte sur AlmaLinux 10.2 (6.12.0-211.7.3.el10_2) le 29 juin 2026 – uid=0 dans les espaces de noms init, dès la première tentative.

Statut : Il s'agit d'un bug de la branche principale, corrigé en amont dans Linux 7.2-rc1 par le commit de fusion 38becddc, qui contient le correctif IPv6 736b380e28d0 et son équivalent IPv4 eca856950f7c. La fenêtre concernée s'étend de la version 6.6 à la version 7.1. Ce matin, il n'y avait pas encore de backports pour la distribution ; mais la situation est déjà en train de changer : AlmaLinux a intégré les correctifs IPv4/IPv6 de l'amont fraggap corrections apportées au code source du paquet « kernel » à 08 h 51 UTC le 30 juin (version 6.12.0-211.28.2). Vérifiez les dépôts de votre distribution avant de supposer que vous attendez toujours une correction.

Niveau de gravité : Élevé pour les systèmes EL10 exposés. Vecteur d'attaque local, faible complexité une fois les conditions préalables réunies, aucune interaction de l'utilisateur et existence d'un exploit public fonctionnel contre une version EL10 par défaut. Il n'y a pas de score CVSS car aucun CVE n'a encore été attribué. Catégorie de faille : débordement linéaire de la mémoire heap/slab → utilisation d'une page après libération (use-after-free) → élévation de privilèges et échappement de l'espace de noms.

Pourquoi est-ce important ? : Le déclencheur est accessible par n'importe quel processus sans privilèges – le commit de correction en amont l'indique clairement : un socket UDPv6 utilisant MSG_MORE ainsi que MSG_SPLICE_PAGES. Aucune capacité d'hôte n'est requise, seulement un accès aux espaces de noms utilisateur sans privilèges à l'intérieur du conteneur. Les hôtes de conteneurs, l'hébergement mutualisé, les environnements d'exécution CI et les environnements Linux multi-locataires sont précisément les environnements où cette faille se produit, car l'exploitation se termine du mauvais côté de la frontière sur laquelle ces plateformes sont construites.

Faites-le tout de suite : Appliquer un noyau fixe ou un KernelCare un correctif ne nécessitant pas de redémarrage, le cas échéant. En attendant, la solution provisoire la plus efficace pour résoudre le problème EL10 consiste à démarrer avec init_on_alloc=1, ce qui réduit l'impact de l'exploit public à un plantage du noyau plutôt qu'à l'obtention d'un shell root – c'est déjà le comportement par défaut à la compilation sous Ubuntu et Debian, ce qui explique pourquoi ce même bogue n'y entraîne qu'un déni de service. Lorsque votre environnement de travail le permet, la désactivation des espaces de noms utilisateur non privilégiés supprime la primitive d'échappement. Considérez ces deux mesures comme des solutions provisoires.

La version longue

« ipv6-frag-escape » est un autre exemple de bogue du noyau Linux qui est passé d’une « petite correction arithmétique » à un « exploit public permettant l’accès aux privilèges root » avant même que la plupart des organisations ne disposent d’un CVE, d’une règle de scan ou d’un avis de fournisseur leur permettant d’agir.

KernelCare a pris connaissance de la démonstration de concept (PoC) rendue publique le 29 juin et a reproduit en interne la vulnérabilité « root » de l'hôte sur une machine AlmaLinux 10.2 standard dès le lendemain matin ; un correctif ne nécessitant pas de redémarrage a été intégré à la version peu après.

Ce dépôt se présente comme un moyen fiable de contourner les restrictions de privilèges et de s'échapper de la « jail » pour CentOS et RHEL 10, en exploitant un bug de fragmentation IPv6 désormais corrigé dans __ip6_append_data() ce qui entraîne un débordement linéaire au sein de la dalle vers skb_shared_info.

Avant d'entrer dans les détails, il convient de préciser un point essentiel : il s'agit d'un bug de la branche principale, et non d'une particularité d'EL10. Tous les noyaux, de la version 6.6 à la version 7.1, qui ne bénéficient pas du correctif, contiennent le code vulnérable. EL10 est simplement la seule cible pour laquelle il existe aujourd'hui un exploit public et exploitable, et les points d'entrée de cet exploit – un EL10 uname Le contrôle, la pagination à 5 niveaux, la désactivation de « init-on-alloc » : ce sont des caractéristiques de l'arme, et non un bug.

Comment fonctionne cette faille

La chaîne va d'une écriture dans un socket sans privilèges à un shell root sur l'hôte :

[Unprivileged socket input]
│  UDPv6 + MSG_MORE + MSG_SPLICE_PAGES
▼
[__ip6_append_data() miscalculation]
│  linear head under-sized by fraggap bytes
▼
[Linear slab overflow]
│  writes past skb->end into skb_shared_info
▼
[Page use-after-free]
│  put_page() drops a ref on an attacker-owned page
▼
[Dirty-Pagetable reclamation]
│  freed page reused as a leaf page table → kernel R/W
▼
[Host namespace escape]
│  credentials overwritten, SELinux neutered, core_pattern hijacked
▼
[Host root shell (uid=0)]

Le bug d'allocation. Dans net/ipv6/ip6_output.c, quand __ip6_append_data() suit la branche d'allocation par pages qu'il calcule alloclen = fragheaderlen + transhdrlen et pagedlen = datalen - transhdrlen. Le problème, c'est que datalen comprend déjà fraggap – les octets reportés du skb précédent, qui sont ensuite copiés dans la tête linéaire. La tête présente donc un déficit exact de fraggap octets pendant que pagedlen est surévalué du même montant.

Le débordement. La copie suivante écrase les données existantes skb->end dans le skb_shared_info situé à la fin de l'objet « head » du paquet lui-même. Un débordement de tas linéaire « in-slab » bien net.

Le déclencheur. Un processus sans privilèges accède au chemin défectueux via une socket UDPv6 en utilisant MSG_MORE ainsi que MSG_SPLICE_PAGES. Ce problème de gestion a été introduit dès la version 6.0 par le chemin d'envoi « zero-copy », mais il est resté inaccessible jusqu'à ce que le MSG_SPLICE_PAGES Dans la section 6.6, laisser le chemin se poursuivre au lieu de revenir en arrière -EINVAL. C'est pourquoi 6,6 constitue la borne inférieure.

Débordement vers les opérations de lecture/écriture du noyau. La corruption confère le contrôle de l'unique nr_frags octet en skb_shared_info. Avec un pointeur de page de tampon de canalisation pré-placé dans une zone non initialisée frags[] démontage d'un emplacement, d'un connecteur (skb_release_data() → put_page()) insère une référence à une page dont l’attaquant a toujours le contrôle, transformant ainsi le débordement en une exploitation de mémoire « use-after-free ». La page libérée est ensuite réutilisée comme table de pages de dernier niveau – ce qui correspond à la condition dite « Dirty-Pagetable » – de sorte qu’une seule page physique sert à la fois de table de pages active et de page que l’attaquant continue de lire et d’écrire via le canal. Une PTE falsifiée avec auto-aliasing étend cette exploitation à des opérations de lecture/écriture à grande échelle au niveau du noyau.

Échapper-se vers l'hôte. À partir des opérations de lecture/écriture au niveau du noyau, le PoC contourne le KASLR en utilisant la table de pages « SMP-trampoline » fixe en mémoire basse, écrase les informations d'authentification du processus, modifie le chemin de refus de SELinux en mémoire et détourne core_pattern Ainsi, un « usermodehelper » s'exécute en tant que root dans les espaces de noms initiaux de l'hôte. Cette dernière étape constitue la voie de sortie.

Le fichier README public documente cette chaîne d'exploitation, mais omet délibérément les mécanismes garantissant sa fiabilité – à savoir la préparation du PCP et la gestion inter-caches qui assurent son fonctionnement cohérent – et limite la portée du binaire fourni à EL10, avec une exigence de pagination à 5 niveaux. Il s'agit d'une preuve de concept, et non d'une arme prête à l'emploi. Deux conséquences sont toutefois importantes pour les défenseurs : une fois l'exploit exécuté, getenforce fait toujours état de Enforcing même si les contraintes imposées par SELinux ont été assouplies et que la corruption se trouve dans la mémoire du noyau plutôt que sur le disque, de sorte que les outils de vérification de l'intégrité des fichiers n'ont rien à signaler.

Ce que modifie le correctif « Upstream »

La correction ne comporte que quelques lignes, ce qui explique justement pourquoi ce problème est facile à sous-estimer. Dans la branche d'allocation paginée IPv6, elle ajoute fraggap à alloclen et le soustrait de pagedlen, de sorte que la tête linéaire soit suffisamment grande pour contenir les octets qui y sont effectivement copiés et que la partie paginée se réduise en conséquence. Elle supprime également le MSG_SPLICE_PAGES exception lors de la vérification de la copie négative.

Le chemin IPv4 dans __ip_append_data() comportait la même erreur comptable et fait l'objet de la même correction (eca856950f7c). IPv6 constitue le cas exploitable le plus grave ; le cas correspondant à IPv4 a été corrigé par souci d'exhaustivité. Étant donné que ces deux fonctions traitent les chemins d'envoi paquet par paquet et ne conservent aucun état persistant, cette correction est un excellent candidat pour un correctif pouvant être appliqué presque tel quel, sans redémarrage.

Qui est concerné ?

La faille est plus large que l'exploit. L'hypothèse de travail la plus sûre est que tout noyau compris entre les versions 6.6 et 7.1 est concerné, à moins qu'il ne dispose du correctif en amont ou d'un backport en aval. Le PoC public, en revanche, est volontairement restreint : il cible les noyaux de la famille EL10 en version 6.12.x, nécessite des espaces de noms utilisateur sans privilèges, suppose une pagination à 5 niveaux (LA57) et dépend de CONFIG_INIT_ON_ALLOC_DEFAULT_ON être en congé.

Exploitation confirmée – présence de « root » sur l'hôte constatée :

• CentOS Stream 10 sur la version 6.12.0-242.el10, citée comme cible par l'auteur de la démonstration de faisabilité.
• RHEL 10 sur la version 6.12.0-228.el10, également mentionnée par l'auteur de la démonstration de faisabilité.
• AlmaLinux 10.2 sur 6.12.0-211.7.3.el10_2, reproduit en interne par KernelCare le 29 juin 2026.

Personnes susceptibles d'être exposées : RHEL 10, CentOS Stream 10, AlmaLinux 10, Rocky Linux 10, Oracle Linux 10 et CloudLinux OS 10 fonctionnant avec des noyaux de la famille EL10 6.12.x concernés, sans le correctif ni le patch sans redémarrage. Ces versions partagent les mêmes conditions de compilation que RHEL 10, notamment init_on_alloc désactivés ; considérez donc qu’ils sont exposés, sauf si vous avez vérifié qu’il en est autrement.

Le bug est présent, la technique publique actuelle se résume à un déni de service :

• Ubuntu 24.04 « Noble » (6.8) et Debian 13 « Trixie » (6.12.x). Les tests effectués par KernelCare ont révélé que CONFIG_INIT_ON_ALLOC_DEFAULT_ON=y sur les noyaux livrés, ce qui remet à zéro le pointeur « stale » implanté et réduit la chaîne à un plantage du noyau plutôt qu’à une évasion vers la racine. Le PoC est également limité à un niveau EL10. uname et à la pagination à 5 niveaux ; il ne fonctionne donc pas sur ces modèles tels qu'ils sont livrés.

Ce résultat, qui se limite à un déni de service (DoS), est propre à la technique actuellement utilisée. Le fichier README indique qu’un autre exploit, tenant compte de l’initialisation lors de l’allocation (init-on-alloc), pourrait voir le jour une fois que le correctif et le CVE auront été rendus publics. Considérez Ubuntu et Debian comme des systèmes exposés mais qui ne peuvent pas encore être exploités, et non comme des systèmes sûrs.

Ce déclencheur ne s'applique pas aux éléments suivants :

• Les noyaux antérieurs à la version 6.6, dans lesquels le MSG_SPLICE_PAGES le chemin est manquant et le déclencheur renvoie -EINVAL.
• Noyaux comportant une fusion 38becddc, correction IPv6 736b380e28d0, correction IPv4 eca856950f7c, ou une adaptation en aval.

Une mise en garde toutefois : un système qui ne répond tout simplement pas aux hypothèses du PoC – la pagination à 4 niveaux, par exemple – n’est pas corrigé. Il est à l’abri de ce PoC précis, mais le bogue du noyau reste présent en arrière-plan.

Agir dès maintenant

La solution définitive consiste à installer un noyau corrigé ou un correctif KernelCare ne nécessitant pas de redémarrage. En attendant que cette solution soit généralisée, il existe deux solutions pratiques.

1. Activez la fonction « init-on-alloc » (recommandé sur EL10). L'exploit public repose sur l'injection d'un pointeur obsolète dans la mémoire « slab » non initialisée. La mise à zéro de la mémoire lors de l'allocation empêche cette attaque. Cette fonctionnalité est déjà activée par défaut sur Ubuntu et Debian ; sur EL10, elle est généralement désactivée.

Vérifiez la configuration du noyau, et non la ligne de commande de démarrage : il s'agit généralement d'un paramètre par défaut défini lors de la compilation, qui n'apparaîtra pas dans /proc/cmdline:

grep CONFIG_INIT_ON_ALLOC_DEFAULT_ON /boot/config-$(uname -r)   # =y means on

Pour l'allumer s'il est éteint :

sudo grubby --update-kernel=ALL --args="init_on_alloc=1"
sudo reboot

Le coût se limite à une légère surcharge de l'allocateur. Le hic, c'est qu'un redémarrage est nécessaire pour que la modification prenne effet ; cette opération s'inscrit donc davantage dans le cadre d'une fenêtre de maintenance que dans celui d'une intervention d'urgence à effectuer dans la minute.

2. Désactiver les espaces de noms des utilisateurs sans privilèges. La chaîne commence par un processus sans privilèges au sein d'un conteneur et repose sur le comportement des espaces de noms sans privilèges. La suppression de cette primitive interrompt le chemin public, quel que soit l'état de l'allocateur.

sysctl user.max_user_namespaces             # check current value
sudo sysctl -w user.max_user_namespaces=0
echo 'user.max_user_namespaces = 0' | sudo tee /etc/sysctl.d/99-ipv6-frag-escape.conf

Cela perturbe le fonctionnement de Podman et Docker sans droits root, certains environnements de sandboxing en CI, les sandboxes de type Flatpak, l'utilisation de la fonction `unshare(1)` sans privilèges, ainsi que les sandboxes de navigateur. Cela ne pose pas de problème sur les profils de serveurs dédiés, mais peut causer des perturbations sur les hôtes de développement et les hôtes de conteneurs. Effectuez des tests avant un déploiement à grande échelle.

Le moment décisif : Si l'hôte n'exécute aucun conteneur sans droits root et que vous pouvez redémarrer le système → définissez init_on_alloc=1; cela reclassifie le bogue en plantage, même si la primitive userns revient plus tard. Si vous ne pouvez pas redémarrer mais que vous pouvez renoncer aux userns sans privilèges → désactivez-la comme solution provisoire sans redémarrage. Si vous avez besoin à la fois de conteneurs sans privilèges root et d’un temps d’indisponibilité nul → le correctif sans redémarrage ou un noyau corrigé est la seule véritable solution, et vous devriez isoler l’exécution locale non fiable jusqu’à ce que l’une de ces solutions soit mise en place.

Correctif sans redémarrage KernelCare

Les deux __ip6_append_data() et __ip_append_data() Il s'agit de chemins d'envoi par paquet sans état persistant entre les appels, ce qui fait de la correction arithmétique en amont un portage kpatch sans problème.

État du flux (30 juin 2026, 09 h 00 UTC) : les versions EL10 ont commencé à être intégrées au flux de test pour RHEL 10, Oracle Linux 10, Rocky Linux 10 et AlmaLinux 10.

Appliquer à partir du flux de test après validation :

sudo kcarectl --update --prefix test

Une fois transféré vers le fil d'actualité principal, il apparaîtra lors de la prochaine mise à jour programmée, ou vous pouvez le publier à la demande :

sudo kcarectl --update

Vérifiez que le patch est actif :

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

Une fois qu'un identifiant CVE a été attribué, kcarectl --patch-info | grep CVE-2026- devrait également le signaler. Par ailleurs, si vous gérez directement des noyaux EL10, AlmaLinux intègre déjà les correctifs en amont dans le code source de son paquet noyau (6.12.0-211.28.2) depuis le 30 juin ; il est donc conseillé de surveiller vos dépôts et les arborescences des autres fournisseurs pour trouver les errata correspondants.

Détection

Il n'existe aucune signature claire post-exploitation pour ce type de faille. La chaîne aboutit à des opérations de lecture/écriture arbitraires au niveau du noyau et peut désactiver l'application de SELinux, alors que les vérifications d'état habituelles semblent toujours rassurantes et qu'aucun changement n'est observé sur le disque. Les indices qui correspondent réellement au comportement de cette faille sont d'ordre comportemental :

• Modifications inattendues apportées à /proc/sys/kernel/core_pattern, en particulier un |- gestionnaire préfixé – le PoC le remplace pour lancer un « usermodehelper » en tant que root.
• Un conteneur ou un processus fils se bloque juste avant le démarrage d'un processus privilégié inhabituel sur l'hôte.
• Lacunes dans l'audit SELinux : l'application est activée, mais les refus attendus ne s'affichent plus sur un hôte qui devrait les générer.

Audit core_pattern et surveillez la séquence « plantage puis exécution avec privilèges ». Considérez ces éléments comme des indices faibles plutôt que comme des preuves. Notez que ce PoC contourne le KASLR grâce à la table de pages fixe « SMP-trampoline » ; il n'a donc pas besoin de lire /proc/kallsyms ou BTF : les indices classiques d'exploitation du noyau n'apparaîtront pas ici. Si un utilisateur ou une charge de travail non fiable ou partiellement fiable a bénéficié d'un droit d'exécution locale sur un hôte EL10 affecté pendant la période d'exposition, privilégiez l'application des correctifs et partez du principe que cet hôte pourrait nécessiter un examen plus approfondi.

Pourquoi celui-ci est important

La vulnérabilité « ipv6-frag-escape » ne permet pas l’exécution de code à distance, et il ne s’agit pas d’un bug qui « fait tomber instantanément toutes les machines Linux ». Pour les hôtes de conteneurs, les plateformes d’hébergement mutualisé, les systèmes d’intégration continue (CI), les environnements de test pour développeurs et les environnements Linux multi-locataires, elle est d’autant plus grave qu’elle fait voler en éclats la frontière même sur laquelle reposent ces plateformes. L’exploitation commence à partir d’un processus sans privilèges et aboutit à l’obtention des droits root dans les espaces de noms initiaux de l’hôte.

Lorsqu’un PoC fonctionnel existe avant la publication d’un CVE ou d’un backport stable, le processus habituel de correction piloté par un scanner ne dispose d’aucun élément déclencheur. Les responsables de la sécurité doivent agir directement en fonction des faits techniques. La correction est mineure, mais l’urgence opérationnelle, elle, ne l’est pas.

Liste de contrôle des mesures correctives prioritaires

1. Appliquez d'abord le correctif (ou le correctif sans redémarrage) aux systèmes EL10 concernés, en particulier aux hôtes de conteneurs et à tous les environnements où du code non fiable ou semi-fiable peut s'exécuter.
2. Activer init_on_alloc=1 lorsqu'un noyau fixe ou un correctif sans redémarrage n'a pas encore été déployé.
3. Désactivez les espaces de noms d'utilisateurs sans privilèges lorsque la charge de travail le permet.
4. Considérez Ubuntu 24.04 et Debian 13 comme des versions « présentant des bogues et pour lesquelles les techniques publiques actuelles sont bloquées », et non comme des versions sûres.
5. Audit core_pattern et les refus de SELinux sur les hôtes exposés.
6. Surveillez l'attribution des CVE et les errata publiés par les fournisseurs en aval, puis réexaminez les systèmes une fois que les backports stables sont disponibles – même si la preuve de concept (PoC) publique n'a jamais été exécutée dans votre environnement.

Références

• Démonstration publique : https://github.com/sgkdev/ipv6_frag_escape
• Correction de la fusion en amont (7.2-rc1) : https://github.com/torvalds/linux/commit/38becddc332c1dbee6ab8dc8f13a860c6280b905
• Correction IPv6 736b380e28d0; Correction IPv4 eca856950f7c; activation des déclencheurs ce650a166335; source de bogues 773ba4fe9104 (IPv6) / 8eb77cc73977 (IPv4)
• Portage du paquet du noyau AlmaLinux (6.12.0-211.28.2) : serveur Git du système d'exploitation AlmaLinux, commit 674503c679

Appliquez des correctifs à tous les noyaux, sans redémarrage. Si vous n'utilisez pas encore KernelCare, c'est le moment idéal pour découvrir comment l'application de correctifs sans redémarrage protège les systèmes Linux critiques, sans nécessiter de fenêtres de maintenance d'urgence ni de temps d'arrêt.

Procurez-vous KernelCare dès aujourd’hui →