Course critique dans la poignée de main TCP du noyau Linux (CVE-2026-98432)

En bref

• Une condition de course dans la poignée de main TCP IPv4 du noyau Linux libère les options IP d'un socket pendant qu'un autre CPU les lit encore. L'équipe CVE du noyau la note CVSS v3.1 9,8 ; le chercheur Xinyang Ge d'Anthropic l'a signalée et Eric Dumazet l'a corrigée le 2026-10-01.
• Tout noyau Linux postérieur à 4.4 est affecté, pour tout service TCP IPv4 joignable par l'attaquant. Les services Go construits avec Go 1.24 ou plus écoutent en MPTCP par défaut, la configuration qu'a exploitée l'attaque d'Anthropic.
• Anthropic indique que son modèle d'IA a écrit un exploit exécutant des commandes en root, sans identifiants, sur des serveurs Linux exposant un écouteur MPTCP. Aucune attaque n'est signalée et la faille n'est pas au catalogue KEV de la CISA au 2026-10-30.
• Installez un noyau corrigé : 5.10.272, 5.15.223, 6.1.190, 6.6.159, 6.12.113, 6.18.56, 7.2.10 ou 7.3, ou le paquet corrigé de votre distribution. Debian, Oracle, Amazon et SUSE livrent en partie ; Ubuntu et RHEL rien au 2026-10-30. Voir « Comment corriger ? » pour la parade réservée à Go.

Suis-je concerné ?

Vous êtes exposé quand toutes ces conditions sont réunies :

• Votre hôte exécute un noyau Linux à partir de Linux 4.4 (janvier 2016) et antérieur aux versions stables corrigées. Les conteneurs n'apportent pas leur noyau : un service en conteneur utilise celui de l'hôte, qui tranche.
• Un service TCP IPv4 de cet hôte est joignable par l'attaquant. Red Hat indique qu'un attaquant distant pouvant atteindre un service TCP exposé peut déclencher la course.
• La course exige un SYN retransmis et des options IP sur la requête de connexion. La cotation de l'équipe du noyau décrit un attaquant envoyant une requête avec des options IPv4 Record Route ou Timestamp, puis la renvoyant : les deux côtés de la course sont induits par l'attaquant.

Deux chemins de configuration élargissent l'exposition. Un serveur avec un écouteur Multipath TCP est la configuration exploitée par Anthropic, et tout programme Go construit avec Go 1.24 ou plus ouvre ses sockets d'écoute en MPTCP par défaut sous Linux. Par ailleurs, la migration de sockets de requête, activée par net.ipv4.tcp_migrate_req=1 ou un programme BPF de migration reuseport, expose le même use-after-free par un second chemin.

Le tableau compte 11 lignes ; 8 portent un correctif publié, les 3 autres non. Amazon Linux 2 et le paquet noyau par défaut d'Amazon Linux 2023 n'ont pas non plus de correctif, et Ubuntu signale ses noyaux cloud, FIPS et temps réel comme vulnérables ou en cours.

Vérifiez ce qui tourne sur chaque hôte :

# Host kernel version
uname -r
# Compare against the fixed versions above; on Ubuntu and RHEL, watch the
# vendor advisory instead, because package versions differ from upstream tags.

# Debian: installed kernel packages and status
dpkg -l 'linux-image*' | grep '^ii'

# RHEL, Oracle Linux, Amazon Linux: installed kernels
rpm -q kernel kernel-uek kernel6.12 kernel6.18 2>/dev/null

# Which Go toolchain built a service (Go 1.24+ enables MPTCP by default)
go version -m /path/to/service | head -1

Comment corriger ?

1. Sous Ubuntu ou RHEL, aucun noyau corrigé n'est installable au 2026-10-30. Red Hat indique qu'aucune atténuation disponible ne répond à ses critères de déploiement aisé, d'adaptation à la plupart des installations et de stabilité. Suivez la page CVE d'Ubuntu et celle de Red Hat, et ne voyez dans l'option Go ci-dessous qu'un dépannage.
2. Installez le paquet corrigé de votre distribution et redémarrez. Sur Debian : apt update && apt install linux-image-amd64, puis redémarrez. Sur Oracle Linux : dnf update kernel-uek, puis redémarrez. Sur Amazon Linux 2023 : dnf update kernel6.18 ou kernel6.12, puis redémarrez.
3. Sur SUSE Linux Micro 6.2 ou openSUSE Leap 16.0 : zypper in kernel-default>=6.12.0-160000.40.1, puis redémarrez.
4. Si vous construisez votre noyau, passez à une des versions stables corrigées. L'équipe CVE du noyau recommande la dernière version stable et indique que la communauté ne soutient pas le cherry-picking de correctifs isolés.

L'équipe sécurité de Go propose une véritable parade pour les services Go 1.24 ou plus, avec sa propre mise en garde. Réglez GODEBUG=multipathtcp=0 dans l'environnement du programme pour désactiver MPTCP à l'exécution, ou placez godebug multipathtcp=0 dans le go.mod du module principal pour le désactiver à la construction. Les programmes peuvent aussi appeler net.ListenConfig.SetMultipathTCP(false) par socket. L'équipe qualifie cette désactivation de MPTCP programme par programme d'atténuation fragile : un seul écouteur MPTCP restant laisse le système exposé, et elle suppose que toute exploitation viable dépend de MPTCP. L'équipe recommande vivement la mise à jour du noyau à la place.

Notez le périmètre : aucune atténuation vendeur ne couvre la course sous-jacente pour les écouteurs hors MPTCP, et Red Hat juge le résultat le plus probable un plantage du noyau, la corruption mémoire restant théorique.

Quelle est la cause racine ?

Le noyau libère les options IP attachées à une requête de connexion TCP pendant qu'un second CPU les lit encore, car la libération utilise kfree() au lieu d'attendre les lecteurs RCU.

La couche IP stocke les options d'une requête de connexion IPv4 entrante, comme Record Route ou Timestamp, avec le socket de requête. Quand la poignée de main se termine, tcp_v4_syn_recv_sock() dans net/ipv4/tcp_ipv4.c remet ce pointeur d'options au nouveau socket enfant au lieu de le copier. Depuis le commit 079096f103fa (« tcp/dccp: install syn_recv requests into ehash table »), les sockets de requête sont traités sans tenir le verrou de l'écouteur.

Le message du commit correctif décrit les deux CPU en collision. Un autre CPU peut traiter concurremment un SYN retransmis pour la même requête et envoyer un SYNACK depuis tcp_check_req(). tcp_v4_send_synack() et inet_csk_route_req() lisent ireq->ireq_opt sous rcu_read_lock() seulement, puis ip_build_and_send_pkt() et ip_options_build() lisent opt->optlen deux fois. Rien n'empêche le socket enfant d'être libéré pendant que ce SYNACK se construit encore.

// net/ipv4/af_inet.c, inet_sock_destruct(), before the fix
void inet_sock_destruct(struct sock *sk)
{
    ...
    WARN_ON_ONCE(sk->sk_wmem_queued);
    WARN_ON_ONCE(sk->sk_forward_alloc);

-   kfree(rcu_dereference_protected(inet->inet_opt, 1));
+   kfree_rcu(rcu_dereference_protected(inet->inet_opt, 1), rcu);

inet_sock_destruct() libère les options du socket enfant par un simple kfree(). Les sockets enfants TCP n'ont pas SOCK_RCU_FREE, donc la libération est immédiate. Un second CPU encore dans rcu_read_lock() lit alors les options libérées dans ip_options_build() : un use-after-free.

// net/ipv4/tcp_ipv4.c, tcp_v4_reqsk_destructor(), before the fix
static void tcp_v4_reqsk_destructor(struct request_sock *req)
{
-   kfree(rcu_dereference_protected(inet_rsk(req)->ireq_opt, 1));
+   kfree_rcu(rcu_dereference_protected(inet_rsk(req)->ireq_opt, 1), rcu);
}

Le second chemin est la migration de sockets de requête, activée par net.ipv4.tcp_migrate_req=1 ou un programme BPF_SK_REUSEPORT_SELECT_OR_MIGRATE. reqsk_timer_handler() clone le socket de requête via inet_reqsk_clone(), si bien que l'ancien socket et son clone partagent le même ireq_opt. Quand le clone est libéré, tcp_v4_reqsk_destructor() libère les options par kfree() alors qu'un autre CPU, tenant une référence sur l'ancien socket, peut encore les utiliser.

IPv6 n'est pas touché par le premier chemin, car tcp_v6_syn_recv_sock() duplique les options. Le commit signale que tcp_v6_reqsk_destructor() porte le même problème de migration pour des options CALIPSO et annonce un correctif séparé.

Comment la faille est-elle exploitée ?

Aucun code d'exploit n'est public. Anthropic décrit l'attaque écrite par son modèle d'IA interne, en quatre étapes :

1. L'attaquant envoie une requête de connexion TCP IPv4 avec des options IP à un service joignable, puis la renvoie pour gagner la course, comme le décrit la cotation de l'équipe du noyau.
2. La course pousse le noyau à lire une longueur contrôlée par l'attaquant et à recopier des octets supplémentaires vers lui. Dès qu'une telle surlecture rend un pointeur du noyau, l'attaquant a vaincu KASLR, la randomisation des adresses du noyau.
3. Le même use-after-free déborde alors un tampon et écrase un pointeur de rappel avec l'adresse d'une charge que l'attaquant a placée en mémoire noyau via une fonctionnalité ordinaire du protocole.
4. Le noyau invoque le rappel. La charge enchaîne des appels à des fonctions existantes du noyau et se termine par une commande shell choisie par l'attaquant, exécutée en root.

Une course perdue ne fait échouer que cette tentative de connexion et ne plante pas le système, donc un attaquant déterminé peut réessayer indéfiniment. Dans la preuve de concept d'Anthropic, la fuite d'un pointeur noyau a pris 48 minutes et l'exécution de la commande shell 5 minutes de plus.

Quel est le flux de l'attaque ?

En une phrase : l'attaquant gagne la course de la poignée de main TCP IPv4 si bien que le noyau libère les options IP de la requête pendant qu'un second CPU les lit encore dans le chemin SYNACK, puis transforme le use-after-free en fuite KASLR et en rappel détourné qui exécute une commande root.

Que peut faire un attaquant ?

Le score 9,8 de l'équipe du noyau suppose un accès réseau, aucun privilège, aucune interaction utilisateur et un fort impact en confidentialité, intégrité et disponibilité (CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H). Dans ce scénario, la faille peut renvoyer de la mémoire voisine du noyau à l'attaquant, corrompre la mémoire noyau ou planter le système.

Anthropic a démontré le résultat le plus fort : des commandes arbitraires en root, sans identifiants ni interaction, sur des serveurs exposant un écouteur MPTCP. Sa publication ne nomme ni la version du noyau ni la configuration testées, et ne dit pas si des serveurs sans écouteur MPTCP sont prenables de la même façon.

Red Hat classe la faille Important, 8,1, avec le vecteur CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:H, sur sa page CVE comme dans son fichier d'avis automatique, mis à jour le 2026-10-29. Selon Red Hat, la faille entraîne surtout un plantage du système (déni de service) ou une corruption mémoire potentielle, et le score reste préliminaire. Oracle, SUSE et Amazon la notent aussi 8,1 avec le même vecteur. Chaque score ne diffère de celui de l'équipe du noyau que par la complexité d'attaque, haute chez les vendeurs, basse chez l'équipe du noyau.

Pourquoi le correctif fonctionne-t-il ?

Le correctif, commit e3f33b0a1d89d738e2b913dab519226eaf76e15b, remplace kfree() par kfree_rcu() dans les deux destructeurs, inet_sock_destruct() et tcp_v4_reqsk_destructor(). kfree_rcu() retarde la libération jusqu'à la fin d'une période de grâce RCU : chaque CPU tenant rcu_read_lock() autour des options finit de les lire avant que la mémoire ne soit rendue. Les lecteurs utilisaient déjà RCU, et les autres chemins remplaçant inet_opt, comme do_ip_setsockopt(), utilisaient déjà kfree_rcu().

Ce changement de deux lignes couvre les deux chemins IPv4 nommés dans le commit : la course SYNACK via inet_sock_destruct() et la course de migration via tcp_v4_reqsk_destructor(). Le commit signale lui-même un point voisin qu'il ne touche pas : le problème équivalent IPv6 pour des options CALIPSO, qu'un correctif séparé traitera.

Comment vérifier si j'ai été compromis ?

Aucune exploitation n'a été signalée nulle part au 2026-10-30, et aucun indicateur ni règle de détection n'a été publié. Une tentative qui perd la course ne fait échouer que cette connexion : un sondage peut laisser peu de traces.

Le mécanisme suggère l'allure d'un sondage massif : de nombreuses tentatives de connexion IPv4 éphémères avec des options Record Route ou Timestamp, suivies de requêtes retransmises vers le même port d'écoute. Traitez ce schéma comme une piste à examiner, pas comme une preuve de compromission ; aucune source publiée ne documente un trafic observé de cette forme.

Chronologie

• 2016-01-10 : Linux 4.4 sort. The Hacker News rapporte que la faille a été introduite dans cette version, avec le changement de sockets de requête qui a ensuite retiré le verrou de l'écouteur du chemin en course.
• 2026-10-01 : Eric Dumazet écrit le correctif « ipv4: free inet_opt and ireq_opt after an RCU grace period », signalé par Xinyang Ge d'Anthropic.
• 2026-10-05 : Les développeurs du noyau appliquent le correctif en amont, dix jours avant la publication du CVE.
• 2026-10-11 au 2026-10-15 : Le correctif est rétroporté vers les branches stables 5.10, 5.15, 6.1, 6.6, 6.12, 6.18 et 7.2.
• 2026-10-15 : L'équipe CVE du noyau publie CVE-2026-98432.
• 2026-10-16 : Debian trixie et Oracle Linux livrent des noyaux corrigés (DSA-6568-1 ; ELSA-2026-500397 à 500399).
• 2026-10-17 au 2026-10-22 : Debian 12 bookworm reçoit des noyaux corrigés en deux avis (DLA-4841-1, DLA-4850-1).
• 2026-10-24 : L'équipe CVE du noyau ajoute le score 9,8 à l'enregistrement, neuf jours après la publication du CVE. Amazon corrige son paquet kernel6.18 (ALAS2023-2026-3251).
• 2026-10-27 : Anthropic publie son billet décrivant l'exploit écrit par IA atteignant root sur des serveurs à écouteur MPTCP.
• 2026-10-29 : Amazon corrige son paquet kernel6.12 (ALAS2023-2026-3335). La page CVE et le fichier d'avis de Red Hat passent à Important, 8,1. SUSE publie des noyaux corrigés pour SLES 15 SP4 à SP6 LTSS et SLE Micro 5.3 à 5.5. The Hacker News publie le tableau d'état des distributions.
• 2026-10-30 : Ubuntu et RHEL ne listent toujours aucun noyau corrigé. Aucune des deux ne donne de date.

FAQ

Mon service Go a-t-il besoin du correctif noyau même s'il n'appelle jamais les API MPTCP ?

Oui. Go 1.24 et plus activent MPTCP par défaut pour les sockets d'écoute sous Linux : un simple net.Listen l'utilise déjà, sans aucun appel MPTCP dans votre code. Vérifiez la construction avec go version -m, et voyez « Comment corriger ? » pour le dépannage GODEBUG.

Les conteneurs sont-ils concernés ?

La faille est dans le noyau de l'hôte : un conteneur ne s'y soustrait pas par l'empaquetage. Tout service TCP IPv4 joignable depuis l'attaquant sur un hôte affecté, en conteneur ou non, donne à l'attaquant la position réseau que la course exige. Le correctif est le paquet noyau de l'hôte.

Les écouteurs IPv6 peuvent-ils aussi être visés ?

Pas par le premier chemin. Le noyau copie les options pour les connexions IPv6, donc la course de poignée de main est propre à IPv4. Le commit correctif signale un problème de migration IPv6 pour des options CALIPSO qu'un correctif séparé traitera.

Pourquoi 9,8 pour l'équipe du noyau et 8,1 chez Red Hat et les autres vendeurs ?

L'équipe du noyau note la complexité d'attaque basse parce que l'attaquant induit les deux côtés de la course : la requête initiale avec options IP et la retransmission. Red Hat, Oracle, SUSE et Amazon notent la complexité haute, ce qui ramène le score à 8,1 avec le même impact élevé sur la confidentialité, l'intégrité et la disponibilité.

La faille est-elle exploitée dans la nature ?

Aucune source ne rapporte d'attaque au 2026-10-30. La faille n'est pas au catalogue KEV de la CISA, vérifié dans le flux JSON du catalogue à cette date. L'exploit d'Anthropic et son test restent la seule exécution démontrée.

Je ne peux pas redémarrer ce mois-ci. Que faire ?

Installez le noyau corrigé dès que votre distribution le publie et, en attendant, appliquez le dépannage MPTCP de l'équipe Go aux services Go 1.24 ou plus, en connaissant ses limites. Red Hat ne publie aucune atténuation validée : maintenez les services IPv4 exposés derrière des listes d'accès réseau strictes et surveillez les avis Ubuntu et Red Hat chaque jour.

Repérez d'abord les hôtes Linux à corriger avec Ostorlab

La découverte de surface d'attaque d'Ostorlab inventorie vos hôtes exposés sur Internet et les services qu'ils ouvrent, pour lister les serveurs Linux portant des écouteurs TCP IPv4 joignables et vérifier leurs noyaux en premier.

Références

• Enregistrement CVE-2026-98432, CNA kernel.org, publié le 2026-10-15, mis à jour le 2026-10-30, CVSS v3.1 9,8 et commits de rétroportage stables : https://cveawg.mitre.org/api/cve/CVE-2026-98432 (consulté le 30 octobre 2026)
• Commit correctif e3f33b0a1d89d738e2b913dab519226eaf76e15b, « ipv4: free inet_opt and ireq_opt after an RCU grace period », Eric Dumazet, 2026-10-01 : https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=e3f33b0a1d89d738e2b913dab519226eaf76e15b (consulté le 30 octobre 2026)
• Anthropic, « Discovering and exploiting vulnerabilities in critical, real-world software with Claude », 27 octobre 2026, chapitre 5 : https://www.anthropic.com/research/discovering-vulnerabilities-with-claude (consulté le 30 octobre 2026)
• The Hacker News, « Linux Kernel TCP Flaw With 9.8 CVSS Score Affects Ubuntu, Red Hat and Other Distributions », 29 octobre 2026, tableau d'état des distributions et justification de la cotation : https://thehackernews.com/2026/10/linux-kernel-tcp-flaw-with-98-cvss.html (consulté le 30 octobre 2026)
• Équipe sécurité Go, « [security] Protecting against CVE-2026-98432 », golang-announce, 29 octobre 2026 : https://groups.google.com/d/msgid/golang-announce/0c2926bc-e90f-4cdb-97c3-300fff6d8885n%40googlegroups.com (consulté le 30 octobre 2026)
• Le même guidage Go transmis sur oss-security, 29 octobre 2026 : https://www.openwall.com/lists/oss-security/2026/10/30/1 (consulté le 30 octobre 2026)
• Page Ubuntu CVE-2026-98432, aucun paquet noyau marqué corrigé au 30 octobre 2026 : https://ubuntu.com/security/CVE-2026-98432 (consulté le 30 octobre 2026)
• Avis automatique Red Hat pour CVE-2026-98432, Important 8,1, mis à jour le 2026-10-29 : https://security.access.redhat.com/data/csaf/v2/vex/2026/cve-2026-98432.json (consulté le 30 octobre 2026)
• Page CVE Red Hat pour CVE-2026-98432 : https://access.redhat.com/security/cve/cve-2026-98432 (consulté le 30 octobre 2026)
• Debian DSA-6568-1, linux 6.12.113-1, 16 octobre 2026 : https://lists.debian.org/debian-security-announce/2026/msg00482.html (consulté le 30 octobre 2026)
• Page d'errata Oracle Linux pour CVE-2026-98432, ELSA-2026-500397 à 500399, publiés le 2026-10-16 : https://linux.oracle.com/cve/CVE-2026-98432.html (consulté le 30 octobre 2026)
• Avis Amazon Linux 2023 ALAS-2026-3251, kernel6.18-6.18.56-125.164, publié le 2026-10-24 : https://alas.aws.amazon.com/AL2023/ALAS2023-2026-3251.html (consulté le 30 octobre 2026)
• Avis Amazon Linux 2023 ALAS-2026-3335, kernel6.12-6.12.113-138.209, publié le 2026-10-29 : https://alas.aws.amazon.com/AL2023/ALAS2023-2026-3335.html (consulté le 30 octobre 2026)
• Page SUSE CVE-2026-98432, Important 8,1, état du correctif par paquet : https://www.suse.com/security/cve/CVE-2026-98432.html (consulté le 30 octobre 2026)
• Fiche NVD de CVE-2026-98432, reprenant le score 9,8 de l'équipe du noyau : https://nvd.nist.gov/vuln/detail/CVE-2026-98432 (consulté le 30 octobre 2026)
• Enregistrement publié par l'équipe CVE du noyau pour CVE-2026-98432, recommandant la dernière version stable : https://kernel.googlesource.com/pub/scm/linux/security/vulns/+/refs/heads/master/cve/published/2026/CVE-2026-98432.mbox (consulté le 30 octobre 2026)
• Documentation du noyau sur Multipath TCP : https://docs.kernel.org/networking/mptcp.html (consulté le 30 octobre 2026)
• Ticket Go suivant la discussion, go.dev/issue/82717 : https://go.dev/issue/82717 (consulté le 30 octobre 2026)
• Flux JSON du catalogue KEV de la CISA, vérifié pour CVE-2026-98432 le 30 octobre 2026 (absent) : https://www.cisa.gov/sites/default/files/feeds/known_exploited_vulnerabilities.json (consulté le 30 octobre 2026)