Vérifier un serveur Linux pour CVE-2026-98432 (use-after-free IPv4 TCP, CVSS 9.8) : cause racine expliquée, script de vérification en lecture seule et mesures d'atténuation.
Comprenez et vérifiez CVE-2026-98432, la condition de course dans la poignée de main TCP IPv4 du noyau Linux qui permet à un attaquant distant d'utiliser de la mémoire noyau libérée. La Frontier Red Team d'Anthropic en a fait un exploit root zero-click contre les serveurs disposant d'un listener multipath TCP (MPTCP). Au 30 octobre 2026, Ubuntu et Red Hat n'ont pas encore de noyau corrigé.
Collez plutôt la sortie de la commande dans le navigateur : https://fbuff.com/tools/cve-2026-98432-checker/ (s'exécute localement, rien n'est téléversé)
Chaque connexion TCP commence par une poignée de main : le client envoie SYN, le serveur répond SYN-ACK, le client réplique ACK. Entre SYN et ACK, le noyau conserve un petit espace réservé pour la connexion à demi-ouverte, un request socket. Si le SYN du client transportait des options IPv4 (Record Route, Timestamp et similaires), le noyau les conserve avec l'espace réservé (ireq_opt), car le SYN-ACK doit les renvoyer en écho.
Lorsque le ACK arrive, tcp_v4_syn_recv_sock() transforme l'espace réservé en socket complet et lui transmet le même bloc d'options au lieu d'une copie. Deux objets pointent désormais vers un seul bloc de mémoire. Lorsque le socket complet est détruit, inet_sock_destruct() libère ce bloc immédiatement avec un simple kfree().
L'espace réservé se trouve dans la table de hachage des connexions établies, que d'autres CPU lisent sans verrou (cette conception provient du commit 079096f103fa, « tcp/dccp: install syn_recv requests into ehash table », Linux 4.4, 2015). Si le client retransmet son SYN au bon moment, un autre CPU renvoie le SYN-ACK et lit les options dans ip_options_build() pendant que le bloc est libéré : un use-after-free.
Imaginez un vestiaire qui remet le même ticket à deux personnes. Quand l'une part, le préposé jette le ticket alors que l'autre se dirige encore vers le comptoir avec celui-ci.
Le correctif (commit amont e3f33b0a1d89, « ipv4: free inet_opt and ireq_opt after an RCU grace period », 7.3-rc7) libère le bloc avec kfree_rcu(), qui attend que chaque CPU ait fini de lire. IPv6 n'est pas affecté par le problème principal car tcp_v6_syn_recv_sock() copie les options. Un second chemin vers la même mémoire existe via la migration de requêtes (net.ipv4.tcp_migrate_req=1 ou un programme BPF_SK_REUSEPORT_SELECT_OR_MIGRATE).
| Évaluateur | Score | Remarque |
|---|---|---|
| Équipe CVE du noyau Linux (CNA) | 9.8 | AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H |
| Red Hat | 8.1 | AC:H : la course est difficile à gagner (préliminaire) |
| Ubuntu | 9.8, priorité High |
MPTCP permet à une connexion d'utiliser plusieurs chemins à la fois. Sous Linux, il est optionnel : un programme doit demander un socket MPTCP, et ss -Mltn liste ceux en écoute. L'exploit d'Anthropic cible les « serveurs Linux disposant d'un listener multipath TCP ». Ni l'enregistrement CVE ni le correctif ne mentionnent MPTCP, et Anthropic n'a pas précisé si des serveurs sans listener MPTCP peuvent être compromis. Un listener MPTCP est le chemin prouvé vers root ; tout serveur non corrigé exécute toujours le code défectueux.
| Distribution | Statut |
|---|---|
| Debian 12 bookworm | Corrigé : linux 6.1.190-1 (DLA-4841-1), linux-6.12 6.12.113-1~deb12u1 |
| Debian 13 trixie | Corrigé : linux 6.12.113-1 (DSA-6568-1) |
| Ubuntu 22.04, 24.04, 26.04, 26.10 | Vulnérable, correctif en cours |
| Ubuntu 16.04, 18.04, 20.04 | Vulnérable |
| Ubuntu 14.04 | Non affecté |
| Red Hat Enterprise Linux | Affecté ; Red Hat indique qu'aucune atténuation ne satisfait ses critères |
| Upstream stable | Corrigé dans 5.10.272, 5.15.223, 6.1.190, 6.6.159, 6.12.113, 6.18.56, 7.2.10 et 7.3 |
curl -fsSLO https://raw.githubusercontent.com/fbuff-tools/cve-2026-98432-checker/main/check.sh
sh check.sh
Le script lit uname -r, /etc/os-release, le changelog du paquet du noyau (rpm -q --changelog, ou apt changelog, qui nécessite le réseau), sysctl net.mptcp.enabled net.ipv4.tcp_migrate_req et ss -Mltn. Il affiche un verdict et se termine avec le code 0 (corrigé ou non affecté), 1 (vulnérable) ou 2 (impossible de déterminer). Il ne fait que lire ; rien n'est envoyé ni modifié. Exécutez-le sur l'hôte : les conteneurs partagent le noyau de l'hôte.
Les noyaux des distributions tels que 6.8.0-85 d'Ubuntu ou 5.14.0-570 de RHEL rétroportent les correctifs sans changer le numéro de version, seul leur changelog peut donc l'indiquer. Les versions de type amont (6.12.113+deb13) sont comparées aux versions corrigées ci-dessus.
sudo apt update && sudo apt full-upgrade # Debian, Ubuntu
sudo dnf upgrade kernel # RHEL family, Amazon Linux 2023
sudo zypper patch # SUSE
sudo reboot
sudo sysctl -w net.mptcp.enabled=0
sudo sysctl -w net.ipv4.tcp_migrate_req=0
printf 'net.mptcp.enabled = 0\nnet.ipv4.tcp_migrate_req = 0\n' | sudo tee /etc/sysctl.d/90-cve-2026-98432.conf
ip_options_build ou ip_build_and_send_pkt (journalctl -k), ou des rafales de SYN avec options IPv4 provenant d'une même source.Aucune des étapes 2 à 4 ne remplace le correctif, et aucun fournisseur ne les a confirmées comme un contournement complet.
Voir aussi : KSMBD checker, HTTP2Shell checker, PHP2Shell checker.
Informations au 30 octobre 2026 ; le statut des correctifs évolue rapidement, consultez donc le tracker de votre fournisseur. Licence MIT. Réalisé par fbuff.