Retour

2026/11/04

CVE-2026-98432 : use-after-free TCP sous Linux, root à distance assisté par IA via MPTCP et défenses pour Linux d’entreprise

Une race condition dans le TCP IPv4 de Linux, un root à distance démontré via MPTCP, et les correctifs pour RHEL, Ubuntu, Oracle Linux et Debian.

Informations vérifiées : 3 novembre 2026 | Analyse technique LOGIQ

En octobre 2026, une vulnérabilité de type use-after-free (UAF), CVE-2026-98432, a été divulguée dans la gestion des connexions TCP IPv4 du noyau Linux. L’équipe CVE du noyau Linux a publié son avis le 15 octobre. Le 27 octobre, Anthropic a indiqué qu’un modèle de recherche interne non publié avait démontré une exécution de commandes à distance, sans authentification et avec les privilèges root, contre un serveur Linux disposant d’un listener MPTCP (Multipath TCP). Il est essentiel de ne pas confondre les conditions précises de cet exploit avec les risques plus larges de vulnérabilité et de déni de service qui concernent les services TCP IPv4 ordinaires.

Points clés

  • La faille est une race condition dans la gestion ordinaire des demandes de connexion TCP IPv4, présente depuis Linux 4.4. MPTCP n’est pas nécessaire pour que le bug existe.
  • La démonstration de root à distance d’Anthropic visait un serveur doté d’un listener MPTCP ; les autres services TCP restent exposés à des plantages, à des dénis de service et à des corruptions de mémoire.
  • Red Hat classe le problème comme critique (CVSS v3.1 9.8) et a publié le 1er novembre des noyaux corrigés pour RHEL 8, 9 et 10. Les correctifs Ubuntu étaient encore en cours le 3 novembre.
  • Installez un noyau corrigé approuvé par l’éditeur, redémarrez et vérifiez le noyau en cours d’exécution. Les mesures d’atténuation réduisent l’exposition mais ne remplacent pas le correctif.

Où se produit la race condition

Le problème concerne la poignée de main TCP en trois étapes sous IPv4. Les options IP détenues par une socket de requête (ireq->ireq_opt) peuvent être transférées dans le champ inet_opt de la socket enfant pendant tcp_v4_syn_recv_sock() sans être copiées. Si un autre CPU traite un SYN retransmis et construit un SYN/ACK pendant que la socket enfant est détruite, la mémoire des options peut être libérée alors qu’elle est encore utilisée. Un accès ultérieur par des fonctions comme ip_options_build() peut alors déclencher un UAF.

Une race condition apparentée existe lors de la migration des sockets de requête via net.ipv4.tcp_migrate_req=1 ou BPF_SK_REUSEPORT_SELECT_OR_MIGRATE, où les données d’options peuvent être partagées entre la socket de requête d’origine et son clone. Le comportement vulnérable remonte à Linux 4.4, mais l’exposition réelle doit être évaluée pour chaque noyau d’éditeur, rétroportages compris.

Le commit de correction upstream e3f33b0a1d89 (« ipv4: free inet_opt and ireq_opt after an RCU grace period ») remplace la libération immédiate dans inet_sock_destruct() et tcp_v4_reqsk_destructor() par une libération différée via RCU avec kfree_rcu(). L’avis CVE de Linux indique des correctifs dans les versions du noyau 6.12.113, 6.18.56, 7.2.10 et 7.3-rc7. Le chemin IPv6 initial ne relève pas de la même vulnérabilité, mais un chemin de migration IPv6 impliquant CALIPSO est traité par un correctif distinct.

Ne pas confondre le root à distance démontré avec l’exposition générale

La preuve de concept d’Anthropic visait un serveur doté d’un listener MPTCP et combinait une fuite d’informations sur les adresses du noyau avec un détournement du flux de contrôle. Selon le rapport, l’expérience a nécessité environ 48 minutes pour obtenir la fuite d’informations, puis cinq minutes de plus pour parvenir à l’exécution de commandes. Comme une race perdue fait seulement échouer la poignée de main sans planter le système, un attaquant peut réessayer indéfiniment. L’UAF sous-jacent se trouve toutefois dans la gestion ordinaire des demandes de connexion TCP IPv4, et pas uniquement dans le code MPTCP.

La même technique d’exploitation menant au root à distance n’a pas été démontrée pour tous les services TCP classiques sans MPTCP. Pour autant, il est également faux de supposer que désactiver MPTCP suffit à rendre un système totalement sûr. Red Hat précise que MPTCP n’est pas une condition nécessaire, que les systèmes où MPTCP est désactivé (la configuration par défaut) restent affectés, et met en garde contre des plantages à distance sans authentification, des dénis de service et des corruptions de mémoire dans les services TCP IPv4 standard.

Évaluations des principaux éditeurs : gravité et état des correctifs

État vérifié au 3 novembre 2026. Les pages des éditeurs évoluent ; consultez toujours l’entrée actuelle avant d’agir.

ÉditeurGravitéÉtat du correctif
Red HatCritique, CVSS v3.1 9.8Noyaux corrigés publiés le 1er novembre : RHEL 8 (RHSA-2026:93414 ; kernel-rt pour NFV RHSA-2026:93415), RHEL 9 (RHSA-2026:93412), RHEL 10 (RHSA-2026:93413). Le kernel-rt de RHEL 9 et OpenShift (RHCOS) sont encore indiqués comme affectés. RHEL 6 et 7 ne sont pas affectés.
UbuntuPriorité High ; CVSS 9.8linux pour 26.10, 26.04, 24.04 et 22.04 : vulnérable, travail en cours. 20.04, 18.04 et 16.04 : vulnérable. Aucun paquet corrigé publié pour l’instant.
Oracle LinuxImportant ; CVSS provisoire 8.1Errata UEK du 16 octobre (ELSA-2026-500397, -500398, -500399) pour OL7 à OL10. Errata RHCK du 2 novembre pour OL8 (ELSA-2026-93414) et OL10 (ELSA-2026-93413) ; aucun erratum RHCK encore publié pour OL9.
Debian(Security Tracker)Corrigé dans bookworm 6.1.190-1 (DLA-4841-1), bookworm linux-6.12 6.12.113-1~deb12u1 (DLA-4850-1) et trixie 6.12.113-1 (DSA-6568-1) ; forky et sid corrigés.

Red Hat (évaluation révisée le 30 octobre ; bulletin mis à jour pour la dernière fois le 2 novembre). La page CVE officielle classe le problème comme critique, CVSS v3.1 9.8, car un attaquant distant non authentifié peut corrompre la mémoire du noyau ou faire planter un système au moyen d’un trafic TCP IPv4 ordinaire. RHEL 8, 9, 10 et OpenShift sont indiqués comme affectés ; le noyau de RHEL 7 est indiqué comme non affecté, car le code concerné en est absent. Depuis le 1er novembre, les données CVE de Red Hat listent les noyaux corrigés : kernel-4.18.0-553.182.1.el8_10 (RHEL 8), kernel-5.14.0-687.64.1.el9_8 (RHEL 9) et kernel-6.12.0-211.72.1.el10_2 (RHEL 10). Le bulletin de sécurité RHSB-2026-016 était encore marqué comme en cours et c’est là que se trouve la procédure d’atténuation. Ne présentez pas des scores plus anciens issus de sources secondaires, comme 5.9 ou 8.1, comme l’évaluation actuelle de Red Hat.

Ubuntu (tableau officiel mis à jour pour la dernière fois le 30 octobre). Le CVE affiche un CVSS de 9.8, tandis que la priorité propre à Ubuntu est High. Les paquets linux standard d’Ubuntu 26.10, 26.04, 24.04 et 22.04 sont marqués « Vulnerable, work in progress », avec les versions correctives prévues indiquées sur la page ; 20.04 est notamment marqué Vulnerable. Les variantes de noyau AWS, Azure, HWE, RT et autres doivent être évaluées une par une. « Work in progress » ne signifie pas qu’un correctif a été publié.

Oracle Linux. L’évaluation propre d’Oracle est Important, avec un score CVSS provisoire de 8.1. Les errata UEK pour OL7, OL8, OL9 et OL10 datent du 16 octobre, et les errata RHCK pour OL8 et OL10 ont suivi le 2 novembre. Les correctifs apportés à UEK ne doivent pas être généralisés à RHCK ni à toutes les versions mineures ; évaluez le noyau installé et les errata exacts.

Debian. Le Security Tracker officiel indique notamment bookworm-security 6.1.190-1 et trixie-security 6.12.113-1 comme corrigés. Vérifiez à la fois les versions des paquets installés et le noyau en cours d’exécution après le redémarrage.

Les résultats CVSS peuvent différer entre le CNA et les éditeurs en raison de configurations et de correctifs propres à chaque distribution, et les évaluations peuvent évoluer. Notez toujours la date de vérification et indiquez le lien vers chaque source officielle.

Mesures défensives : l’atténuation ne remplace pas un correctif

La priorité absolue est d’installer un noyau corrigé approuvé par l’éditeur et de vérifier la version en cours d’exécution après le redémarrage. Lorsqu’aucun correctif n’est encore disponible, envisagez de fermer les services TCP publics inutiles, de restreindre les réseaux source autorisés et de surveiller en priorité les hôtes exposés.

Le bulletin de Red Hat décrit une mesure d’atténuation nftables qui rejette les paquets TCP IPv4 entrants portant des options IP dans l’en-tête IPv4 :

table inet cve_2026_98432 {
  chain input {
    type filter hook input priority -310; policy accept;
    ip protocol tcp ip hdrlength > 5 counter drop
  }
}

Cette mesure n’offre pas une protection complète, peut perturber les charges de travail qui reposent sur les options IP et doit être testée pour son impact sur le trafic métier avant d’être déployée. Les options TCP ordinaires de l’en-tête TCP restent autorisées ; il ne s’agit pas de bloquer le champ TCP Options. Sur OpenShift, les règles au niveau des nœuds ne filtrent pas le trafic de pod à pod à l’intérieur du réseau du cluster ; le filtrage à la périphérie du réseau y est donc important. Supprimez la table dès que le noyau corrigé est en cours d’exécution.

Conseil : après l’application du correctif, comparez la sortie de uname -r avec la version corrigée indiquée dans l’erratum de votre éditeur, et conservez cette sortie avec le dossier de changement. Un paquet installé mais pas encore démarré ne ferme pas la vulnérabilité.

Sous Linux, le package net de Go 1.24 et versions ultérieures active MPTCP par défaut pour les listeners. L’équipe Go documente GODEBUG=multipathtcp=0 comme moyen de le désactiver (également disponible sous forme de ligne godebug dans go.mod). Une proposition visant à changer ce comportement par défaut est toujours en discussion, et les mainteneurs de Go indiquent qu’un noyau corrigé est la véritable solution. Ce réglage peut réduire l’exposition au chemin d’attaque dépendant de MPTCP démontré par Anthropic, mais il ne corrige pas l’UAF du noyau lui-même. Examinez l’utilisation de MPTCP service par service.

Le point de vue de LOGIQ

En maintenance de Linux d’entreprise, on ne peut pas juger de la sécurité à partir d’un score CVSS public ou de la seule sortie de uname -r. Évaluez ensemble la version du système d’exploitation, la famille de noyau (UEK ou RHCK, par exemple), la version du paquet, le noyau actuellement démarré, l’exposition réseau, les réglages MPTCP, les errata de l’éditeur et les preuves de redémarrage. Suivez toute la chaîne, de l’analyse d’impact et de la validation jusqu’au déploiement et à la surveillance en exploitation.

Lorsque les correctifs des éditeurs se font attendre, documentez le risque résiduel lié aux mesures d’atténuation temporaires et réévaluez ces mesures une fois les correctifs disponibles. À mesure que l’IA rend les vulnérabilités plus faciles à exploiter en pratique, la maintenance en entreprise doit couvrir tout le cycle de vie : détection, vérification, correction et preuve d’un fonctionnement sain.

Sources primaires et références