Linux : quatre failles avec exploits publics, quels serveurs patcher ?

Quatre failles du noyau Linux disposent désormais d’exploits publics permettant une élévation locale vers root : DirtyAH6, TUNderflow, PPPoEject et DiagSpill. Le chercheur Asim Manizada a publié son analyse et ses démonstrations le 18 septembre 2026, après coordination avec les mainteneurs. Publication du chercheur.

Pour un parc Linux, la priorité est de rapprocher ces alertes des machines réellement exploitées : noyau actif, fonctions disponibles, droits accordés aux utilisateurs et aux conteneurs. Une liste de CVE ne constitue pas encore un plan de maintenance.

Quatre failles réseau, quatre points de contrôle

Les vulnérabilités touchent des composants distincts. Avoir corrigé une précédente faille Linux ne permet donc pas de considérer cette nouvelle série comme couverte.

Faille	Identifiant	Composant et défaut corrigé
DirtyAH6	CVE-2026-80844	AH6 / IPsec IPv6 : validation insuffisante d’un en-tête de routage, avec accès mémoire hors limites.
TUNderflow	CVE-2026-81000	TUN/TAP : calcul de taille incorrect après une demande excessive d’espace en tête de paquet, notamment transmise par Open vSwitch.
PPPoEject	CVE-2026-68121	PPPoE : réutilisation d’un pointeur devenu invalide après réallocation d’un tampon réseau.
DiagSpill	CVE-2026-74469	SCTP : débordement d’un compteur entraînant une allocation trop petite pour une réponse de diagnostic.

Les descriptions techniques et le suivi des paquets sont disponibles dans les fiches Canonical : DirtyAH6, TUNderflow, PPPoEject et DiagSpill.

Le point commun est une corruption de mémoire dans le noyau. L’enjeu dépasse alors les droits du compte initialement compromis : réussir une élévation vers root remet en cause la confiance dans la machine entière.

Exploit public ne signifie pas attaque distante universelle

Les démonstrations sont adaptées à des environnements précis. Le dépôt DirtyAH6 documente notamment des prérequis de noyau, de mémoire et de création d’espaces de noms utilisateur et réseau. Il avertit aussi que le test modifie la configuration d’authentification et peut bloquer la machine. Ce n’est pas un outil de diagnostic à lancer sur un serveur de production. Avertissements et prérequis du chercheur.

TUNderflow et PPPoEject disposent également de démonstrations destructrices, prévues pour des systèmes de test jetables. La disponibilité de ces programmes établit une possibilité d’exploitation ; elle ne prouve pas une campagne d’attaques en cours. Documentation TUNderflow, documentation PPPoEject.

Les scénarios distants sont particuliers. DirtyAH6 peut provoquer un déni de service sur certaines passerelles IPv6 utilisant AH en mode transport. Le résultat root distant décrit en laboratoire supposait une préparation de la mémoire cible. Pour DiagSpill, le scénario distant décrit concerne un déni de service avec des options SCTP non activées par défaut. Limites détaillées dans l’analyse originale.

Pour l’exploitation quotidienne, le scénario à examiner en premier reste donc celui d’un accès local limité : utilisateur, application compromise ou tâche automatisée exécutant du code non fiable.

Quels serveurs traiter en priorité ?

Notre recommandation est de commencer par les systèmes où une exécution de code peu privilégiée est plausible et où une compromission root aurait un impact important :

• runners CI/CD et machines de construction exécutant des contributions externes ;
• serveurs partagés entre plusieurs utilisateurs ou applications ;
• hôtes de conteneurs, en examinant leurs capacités et leur isolation ;
• passerelles et serveurs réseau dont les fonctions concernées sont utilisées ;
• machines sensibles où la correction du noyau reste en attente.

Cette hiérarchisation ne remplace pas la qualification technique. Elle sert à ordonner le travail une fois le parc inventorié.

Sur Ubuntu, la présence de correctifs amont ne signifie pas que chaque variante du noyau est déjà corrigée. Au 22 septembre, la fiche DirtyAH6 indique encore plusieurs paquets vulnérables, notamment le paquet linux de versions LTS. Il faut consulter la ligne correspondant au paquet effectivement déployé, pas seulement le nom de la distribution. Suivi Canonical de CVE-2026-80844.

Proxmox : séparer le noyau de l’hôte et celui des VM

Une VM Linux possède son propre noyau. Corriger l’hôte Proxmox ne corrige donc pas automatiquement les systèmes invités. Inversement, une élévation root dans une VM ne démontre pas, à elle seule, une sortie de VM vers l’hyperviseur.

Les conteneurs partagent le noyau de leur hôte. Mettre à jour leurs seuls paquets applicatifs ne remplace pas la maintenance de ce noyau. Le chercheur évoque une sortie de conteneur possible à partir de ces défauts, sans l’avoir développée dans ses démonstrations. Périmètre de la recherche.

Dans un inventaire Proxmox, nous distinguerions donc trois lignes de maintenance : les nœuds, les VM Linux et les services conteneurisés. Aucun numéro de paquet Proxmox corrigé n’est déduit ici des seules versions amont : la couverture doit être confirmée dans les informations du fournisseur.

Quels noyaux contiennent les quatre correctifs ?

Le chercheur donne les premiers seuils stables amont réunissant les quatre corrections :

Branche Linux amont	Première version réunissant les quatre correctifs
5.10	5.10.270
5.15	5.15.221
6.1	6.1.188
6.6	6.6.157
6.12	6.12.109
6.18	6.18.50
7.2	7.2.4

Source : synthèse des correctifs amont.

Ce tableau n’est pas une consigne pour installer un noyau générique sur votre distribution. Les éditeurs rétroportent des corrections et conservent leur propre numérotation. La référence opérationnelle reste le paquet maintenu pour votre système, avec confirmation des quatre CVE.

Pour relever le noyau actuellement chargé :

uname -r

Cette commande sert à l’inventaire. Elle ne certifie pas, seule, la présence des correctifs.

Mitiger sans casser le réseau

Restreindre les espaces de noms non privilégiés réduit certains chemins, mais ne couvre pas DiagSpill, ni les processus disposant déjà des capacités réseau nécessaires. Analyse des mitigations.

Dans votre environnement, une restriction peut aussi interrompre des usages légitimes : conteneurs rootless, sandboxes ou traitements CI. De même, désactiver TUN/TAP à l’aveugle peut affecter la connectivité de services ou de machines virtuelles.

Nous privilégierions donc une mesure compensatoire ciblée, testée et documentée, seulement si le correctif ne peut pas être appliqué immédiatement. L’absence d’un module dans lsmod n’est pas une preuve suffisante : une fonction peut être intégrée au noyau ou chargeable ultérieurement.

Fermer l’alerte après validation, pas après téléchargement

Notre séquence de maintenance serait la suivante :

1. Qualifier le parc : hôte, VM ou conteneur, noyau chargé et usages réseau.
2. Vérifier les quatre CVE dans le suivi du fournisseur, en conservant la version de paquet attendue.
3. Préparer l’intervention : sauvegardes restaurables, console de secours et fenêtre de maintenance.
4. Installer puis activer la correction : prévoir le redémarrage ; ne présumer aucune couverture par un service de livepatch sans confirmation explicite.
5. Contrôler après intervention : noyau actif, réseau, applications, supervision et sauvegardes.

Sur un cluster, traiter les nœuds successivement suppose de vérifier capacité restante, quorum et état du stockage. La migration des VM peut réduire l’interruption, mais ne constitue pas une garantie universelle de maintenance transparente. Nous détaillons cette préparation dans notre article sur les correctifs du noyau Linux et la maintenance des clusters Proxmox.

Si une compromission est suspectée, corriger la faille ne suffit pas à rétablir la confiance. Il faut préserver les éléments d’analyse, examiner les accès et les persistances, puis décider d’une reconstruction et du renouvellement des secrets selon le périmètre touché.

Le bon objectif n’est pas seulement « les mises à jour sont installées ». C’est « les quatre failles sont couvertes par le noyau actif, et les services ont été validés ». C’est le lien indispensable entre veille CVE et exploitation d’une infrastructure Linux.

Analyse documentaire au 22 septembre 2026. Nous n’avons pas exécuté les exploits ; les statuts des paquets peuvent évoluer après cette date.