blacksloth.fr

CVE-2026-98432 (noyau Linux) : Debian et Ubuntu récentes corrigées, RHEL en attente

La faille CVE-2026-98432 touche la gestion des connexions TCP en IPv4 dans le noyau Linux. Référencée depuis le 15 octobre 2026, elle est corrigée en amont dans le noyau 7.3-rc7, mais son arrivée dans les distributions est très inégale. Au 13 novembre 2026, Debian, SUSE en partie et les versions récentes d’Ubuntu proposent des noyaux corrigés ; les Ubuntu les plus anciennes et Red Hat Enterprise Linux (RHEL) n’en proposent pas encore.

Une course entre deux processeurs

Quand une connexion TCP s’établit, le noyau transfère les options IP de la demande de connexion vers la nouvelle socket, sans en faire de copie. Si un autre processeur traite au même moment la retransmission de cette demande et construit sa réponse (le SYNACK) avec ces mêmes options, la socket enfant peut être libérée entre-temps. Le noyau lit alors de la mémoire déjà rendue : c’est un use-after-free.

Le correctif retarde la libération jusqu’à la fin d’une période de grâce RCU (read-copy-update), ce qui laisse aux lecteurs concurrents le temps de finir d’utiliser les objets concernés. Le suivi de Debian renvoie vers le commit amont, intégré dans la version 7.3-rc7. Un problème voisin existe lors de la migration de demandes de connexion, et IPv6 n’est pas concerné par le premier défaut.

La note de gravité est de 9,8 sur 10 chez Ubuntu, chez l’équipe CVE du noyau et chez Red Hat, qui la qualifie de critique pour RHEL. SUSE se démarque avec un score CVSS 3.1 de 8,1, une complexité d’attaque élevée et une gravité « importante ». Red Hat reconnaît d’ailleurs que l’exploitation exige un minutage précis des requêtes réseau, mais aucun privilège.

Ce qu’affirme Anthropic, et ce qui est établi

Le 27 octobre 2026, Anthropic a publié un billet de recherche décrivant cinq chaînes d’exploitation, dont une contre ce défaut du noyau. Selon l’entreprise, « un modèle de recherche interne non publié » a écrit un exploit en deux temps : il contourne d’abord l’aléa d’adressage du noyau (KASLR), puis exécute une commande arbitraire avec les droits root, sans identifiant ni interaction. La preuve de concept demanderait 48 minutes pour fuiter un pointeur du noyau et environ cinq de plus pour obtenir l’exécution, soit environ 53 minutes au total. Une course perdue ne fait échouer que la poignée de main, ce qui permet de recommencer.

Il s’agit d’une affirmation de l’éditeur du modèle, et les sources consultées ne font état d’aucune reproduction indépendante. La démonstration visait un serveur doté d’un écouteur MPTCP (Multipath TCP), une option activée seulement sur demande. BleepingComputer rappelle qu’aucune exécution de code à distance n’a été démontrée publiquement sans MPTCP, même si la faille concerne aussi le TCP ordinaire, et ne signale aucune exploitation dans la nature au 30 octobre. Red Hat va plus loin dans son bulletin RHSB-2026-016 : désactiver MPTCP ne bloque qu’une voie d’attaque, et RHEL, qui le désactive par défaut, reste concerné.

État des correctifs

La situation a évolué depuis les premiers articles. Le 30 octobre, la presse (CSO Online, BleepingComputer) rapportait qu’Ubuntu et RHEL n’avaient pas de noyau corrigé. Les pages officielles des éditeurs, consultées le 13 novembre, donnent désormais le tableau suivant.

  • Ubuntu : le paquet linux est corrigé en 26.10 (7.3.0-10.10), 26.04 LTS (7.0.0-43.43), 24.04 LTS (6.8.0-149.149) et 22.04 LTS (5.15.0-203.213). Pour les versions 20.04, 18.04 et 16.04, Canonical indique « vulnérable, travail en cours ». Les variantes cloud (AWS, Azure, GCP, Oracle) ont leurs propres numéros de version.
  • Debian : Debian 12 (6.1.190-1) et Debian 13 (6.12.116-1) sont corrigées via les dépôts de sécurité, tout comme testing et unstable. Les versions des dépôts principaux antérieures à ces mises à jour de sécurité (6.1.176-1 et 6.12.107-1) restent marquées vulnérables. Pour Debian 13, BleepingComputer cite toutefois la version 6.12.113-1, ce qui diverge du suivi de Debian.
  • SUSE : l’état global reste « en attente », mais des paquets corrigés sont déjà publiés pour plusieurs produits, par exemple kernel-default 6.4.0-150700.53.90.1 pour SLES 15 SP7, 4.12.14-122.339.1 pour SLES 12 SP5-LTSS et 5.14.21-150400.24.246.1 pour SLES 15 SP4-LTSS.
  • Red Hat : RHEL 8, 9 et 10 sont concernés, ainsi qu’OpenShift 4. Le bulletin, mis à jour le 11 novembre, ne cite aucune version corrigée et indique que Red Hat « accélère » la publication des correctifs. RHEL 7 n’est pas concerné, d’après BleepingComputer.

Les chiffres demandent d’ailleurs un peu de prudence. Fin octobre, BleepingComputer attribuait à Red Hat un score de 5,9 et parlait d’un déni de service potentiel, alors que la page actuelle de Red Hat affiche 9,8 et une gravité critique. L’éditeur a visiblement révisé son évaluation, ce que les sources lues ne permettent pas de dater précisément.

Que faire

Il est conseillé aux administrateurs d’installer sans attendre les noyaux corrigés disponibles. Pour les systèmes qui n’ont pas encore de correctif (Ubuntu 20.04, 18.04 et 16.04, RHEL), la page d’Ubuntu, où elle est signée par un contributeur, et le bulletin de Red Hat décrivent la même mesure d’attente : une règle nftables qui rejette les paquets TCP IPv4 portant des options IP. Elle réduit le risque sans le supprimer, peut perturber des services légitimes et ne remplace pas la mise à jour. BleepingComputer cite en outre la restriction des services exposés à des réseaux de confiance, et rappelle que la désactivation de MPTCP seule ne suffit pas.

Reste à savoir à quelle vitesse Red Hat et Canonical combleront leurs retards, et si l’exploit décrit par Anthropic sera un jour reproduit de façon indépendante.

Sources

In

, , , , ,
Enable Notifications OK No thanks