Faille TCP de Linux : le score CVSS passe à 9,8

Red Hat a relevé le 2 novembre le score CVSS de la faille du noyau Linux CVE-2026-98432 à 9,8, alors qu'elle lui avait attribué auparavant des notes comprises entre 5,9 et 8,1. L'éditeur a publié le 1er novembre des noyaux corrigés pour RHEL 8, 9 et 10. Chez Ubuntu, le correctif est toujours en cours.

La faille se situe dans la procédure d'établissement des connexions TCP sur IPv4 et peut être déclenchée depuis le réseau, sans authentification ni action de l'utilisateur. Le périmètre touché remonte à Linux 4.4, et la cause profonde est un commit de 2015.

Une situation de concurrence corrigée en deux lignes

Lorsqu'un paquet SYN transporte des options IPv4 (par exemple Record Route ou Timestamp), le noyau les stocke sur le socket de requête. À la fin de la poignée de main, le pointeur vers cette mémoire est transmis directement au socket enfant, sans copie : les deux partagent la même zone.

Si, à ce moment-là, un autre CPU est en train de construire un SYN-ACK pour un SYN retransmis et que le socket enfant est détruit au même instant, la mémoire des options est libérée aussitôt par kfree(). Le chemin qui construit le SYN-ACK lit alors de la mémoire déjà libérée.

Le correctif est signé Eric Dumazet (commit e3f33b0a1d89). Il remplace kfree() par kfree_rcu(), ce qui retarde la libération jusqu'à la fin du délai de grâce RCU, et ne touche que deux lignes. Le signalement vient de Xinyang Ge, d'Anthropic. L'entrée CVE a été publiée le 15 octobre ; les versions corrigées des branches stables sont les 5.10.272, 5.15.223, 6.1.190, 6.6.159, 6.12.113, 6.18.56 et 7.2.10, et la 7.3 pour la branche principale.

Ce qu'avance Anthropic, elle seule peut le prouver

Ce qui a attiré l'attention sur cette faille est un article de l'Anthropic Frontier Red Team daté du 27 octobre. Selon ce texte, un modèle interne non publié a écrit pour l'équipe un programme d'exploitation permettant à un attaquant distant non authentifié d'exécuter des commandes en tant que root sur des serveurs où l'écoute MPTCP est activée.

L'exploitation se déroule en deux temps : la situation de concurrence sert d'abord à lire la mémoire du noyau hors limites, à divulguer des pointeurs et à contourner KASLR ; une écriture hors limites écrase ensuite un pointeur de fonction de rappel. Anthropic indique environ 48 minutes pour divulguer le pointeur, puis environ 5 minutes de plus pour obtenir l'exécution de commandes.

Plusieurs points sont à distinguer. Le code de l'exploit, les versions de noyau testées et la configuration n'ont pas été publiés, et aucune vérification par un tiers n'existe à ce jour. Ni l'entrée CVE ni le commit de correction ne mentionnent MPTCP, et l'article n'explique pas pourquoi il serait indispensable. Les 53 minutes proviennent d'un environnement inconnu et ne se transposent pas telles quelles à des serveurs en production. Au 2 novembre, aucun éditeur, aucun CERT ni l'équipe CVE du noyau n'a signalé d'exploitation dans la nature, et le catalogue des vulnérabilités connues et exploitées de la CISA ne la recense pas non plus.

Certains articles diffusés en chinois écrivent qu'« Anthropic a publié des exemples d'exploitation ». Plus exactement, c'est la description du déroulement de l'exploitation qui a été publiée, et non du code exécutable.

Le désaccord sur le score persiste également. L'équipe CVE du noyau et Red Hat retiennent désormais 9,8, tandis qu'Oracle, SUSE et Amazon retiennent 8,1 ; la différence tient à la complexité d'attaque, jugée faible ou élevée. Le NVD n'a pas encore publié son propre score.

Go a fait du prérequis une valeur par défaut

L'avis de l'équipe de sécurité de Go du 29 octobre a élargi la portée du problème. Depuis Go 1.24, la valeur par défaut de multipathtcp est 2, ce qui signifie que MPTCP n'est activé que côté écoute. Autrement dit, un programme Go qui lance un service avec net.Listen remplit par défaut le prérequis démontré par Anthropic.

L'atténuation proposée par l'équipe Go consiste à définir GODEBUG=multipathtcp=0 à l'exécution, ou à écrire godebug multipathtcp=0 dans le go.mod du module principal ; elle qualifie en même temps cette désactivation programme par programme de « a fragile mitigation » (une atténuation fragile). L'équipe Go estime qu'il est trop tôt pour changer la valeur par défaut. Côté noyau, on peut fixer net.mptcp.enabled à 0 ; cela ne supprime que le prérequis démontré, la faille elle-même demeure.

Ce que les administrateurs peuvent faire en priorité

L'état des distributions (vérifié en partie le 29 octobre, en partie le 2 novembre) est à peu près le suivant :

Ubuntu représente une part non négligeable des utilisateurs de serveurs cloud : c'est la ligne de ce tableau qu'il faut surveiller de plus près. Les distributions corrigent surtout par rétroportage ; pour savoir si un système est à jour, il faut donc comparer les versions de paquets avec le bulletin de sécurité de la distribution, et se fier uniquement au numéro de version majeur de uname -r peut induire en erreur. L'installation d'un nouveau noyau exige un redémarrage ; le live patching est un autre mécanisme, à confirmer séparément.

Pour les machines qui ne peuvent pas encore recevoir de correctif, on peut commencer par recenser les services à l'écoute en MPTCP, en particulier les binaires compilés avec Go 1.24 ou une version ultérieure, puis décider de les désactiver ou non selon les méthodes ci-dessus. Les éditeurs n'ont pas confirmé que la désactivation de MPTCP supprime tout le risque ; cette étape ne fait que gagner du temps. Si les journaux de plantage du noyau font apparaître des fonctions comme ip_options_build, il faut aussi enquêter.

Sources : comptes rendus publics de l'article de l'Anthropic Frontier Red Team, bulletin de vulnérabilité de Rescana, CocoLoop, avis de l'équipe de sécurité de Go, pages de suivi de sécurité de Debian et de Red Hat ; les scores et l'état des correctifs suivent les indications publiées par chaque éditeur, et les détails d'exploitation d'Anthropic n'ont pas été vérifiés de manière indépendante.