Contexte technique
CVE‑2026‑98432 désigne une use‑after‑free dans le chemin de poignée de main IPv4 du noyau Linux. Le défaut apparaît lorsque deux processeurs traitent simultanément un socket de requête et son socket enfant tout en partageant le même objet d’options IP. L’un des chemins libère immédiatement cet objet, alors que l’autre, protégé uniquement par une section critique RCU, continue de le lire. Le résultat est un pointeur noyau obsolète exploitable via le trafic réseau.
Mécanisme de la vulnérabilité
Lors du côté serveur d’un handshake TCP, le noyau crée un request socket léger. La fonction tcp_v4_syn_recv_sock() transfère le pointeur ireq_opt du socket de requête vers le socket enfant sous le nom inet_opt sans duplication. En parallèle, un second CPU peut recevoir un SYN retransmis lié à la même requête et appeler tcp_check_req(), tcp_v4_send_synack() ou inet_csk_route_req() qui lisent les options IP dans une section RCU. La libération se fait avec kfree(), qui rend la zone mémoire réutilisable immédiatement, alors que les lecteurs RCU peuvent encore y accéder. Le correctif remplace ces libérations par kfree_rcu(), retardant la récupération jusqu’à la fin d’une période de grâce RCU.
/* upstream fix */
- kfree(inet_opt);
+ kfree_rcu(inet_opt, rcu);
Le même problème apparaît lorsqu’une migration de requête est activée (net.ipv4.tcp_migrate_req=1) ou lorsqu’un programme BPF BPF_SK_REUSEPORT_SELECT_OR_MIGRATE contrôle la migration. Le correctif modifie inet_sock_destruct() et tcp_v4_reqsk_destructor() pour utiliser la libération RCU‑aware.
Analyse des scores et de l’exploit
Le registre CVE attribue un score CVSS 3.1 de 9.8, reflétant une attaque réseau non authentifiée avec impact maximal sur la confidentialité, l’intégrité et la disponibilité. Red Hat, en évaluant la difficulté de la course et les mitigations présentes dans ses paquets, propose un score de 5.9. Anthropic Frontier Red Team a démontré une chaîne d’exécution de code à distance contre un serveur Linux équipé d’un écouteur Multipath TCP (MPTCP) en laboratoire contrôlé. Cette preuve montre que, sous une configuration précise, le défaut peut être exploité pour obtenir les privilèges root, mais elle ne prouve pas une compromission généralisée de tous les services TCP.
Recommandations de mitigation
Les administrateurs doivent d’abord identifier les services TCP exposés, puis vérifier la version exacte du noyau fourni par le distributeur. L’application du correctif fourni par le vendeur, suivie d’un redémarrage, constitue la réponse immédiate. Les hôtes qui offrent des écouteurs MPTCP méritent une attention prioritaire, car la chaîne d’exploitation publique cible spécifiquement ce scénario. De même, les passerelles Internet, les équilibreurs de charge, les nœuds Kubernetes, les points de terminaison VPN, les reverse proxies et les appliances réseau basées sur Linux doivent être inventoriés et mis à jour, même si MPTCP n’est pas explicitement activé.
Les scanners qui se basent uniquement sur uname -r peuvent générer des faux positifs ou négatifs, les distributions backportant les correctifs tout en conservant un numéro de version antérieur. Il est donc recommandé de croiser les informations du scanner avec les bulletins de sécurité du fournisseur ou les listes de paquets corrigés (Debian security tracker, Ubuntu CVE page, etc.). Conserver les journaux de démarrage permettant de confirmer la présence du correctif en mémoire renforce la traçabilité post‑incident.
