Use-after-free TCP sous Linux : patcher ou atténuer ?

Votre noyau contient un use-after-free joignable à distance dans le chemin de la poignée de main TCP, votre distribution n'a pas encore livré de correctif, et quelqu'un a déjà démontré un exploit root fonctionnel. Alors, quel est le plan : attendre sagement, ou commencer à jeter des paquets au niveau du pare-feu ? Le use-after-free TCP de Linux divulgué sous le nom CVE-2026-98432 est un cas d'école de la plus vieille décision des opérations de sécurité, patcher ou atténuer, et la réponse honnête est que les deux options ne sont pas du tout symétriques. L'une des deux corrige réellement le problème.

J'ai été des deux côtés de ce genre de décision. J'ai déjà retardé un déploiement d'urgence du noyau parce que la mitigation semblait suffisante sur le papier, et j'ai aussi vu une règle de pare-feu « temporaire » pourrir tranquillement en production pendant huit mois, pendant que tout le monde oubliait la CVE qu'elle masquait. Ce bug est un bon prétexte pour expliquer quand chaque approche gagne, parce que les compromis sont ici exceptionnellement lisibles.

Ce qu'est réellement le use-after-free TCP

La mécanique compte, car elle détermine ce qu'une mitigation peut et ne peut pas faire. Quand votre serveur accepte une connexion TCP IPv4, le noyau suit la poignée de main à moitié ouverte dans une socket de requête allégée, puis la promeut en socket complète une fois la poignée de main terminée. Si l'en-tête IPv4 du pair contenait des options, le noyau les sauvegarde pour les renvoyer dans ses réponses. Le bug : le noyau transmettait ces options sauvegardées à la nouvelle connexion sans les copier, puis les libérait immédiatement, alors qu'un autre CPU pouvait encore les lire pour construire une réponse de poignée de main. C'est un use-after-free, joignable par un pair distant et non authentifié, avant même qu'une seule ligne de votre code applicatif ne s'exécute.

Le correctif amont, signé Eric Dumazet, tient en quatre lignes : deux appels simples à kfree() deviennent kfree_rcu(), ce qui reporte la libération jusqu'à ce que chaque lecteur ait fini d'utiliser la mémoire. C'est le correctif canonique du noyau pour cette classe précise de bugs : les lecteurs sous RCU détiennent des références que vous ne voyez pas, donc on laisse expirer la période de grâce avant de récupérer la mémoire. Le CNA du noyau lui a attribué un score CVSS de 9,8. Red Hat l'avait d'abord noté 8,1, avant de le relever à 9,8 (critique) le 30 octobre, en invoquant l'absence de prérequis réseau.

Deux détails modifient le calcul de l'exposition. D'abord, la course échoue en douceur : une tentative ratée fait simplement échouer la poignée de main sans faire paniquer la machine, donc un attaquant peut réessayer indéfiniment. Ensuite, le chemin d'exploitation démontré par Anthropic cible les hôtes disposant d'un écouteur TCP multichemin. Selon la Go Security Team, les programmes Go ouvrent des écouteurs MPTCP par défaut sous Linux depuis Go 1.24, partout où le noyau le permet. Vérifiez votre parc :

ss -Mlnp                 # MPTCP listeners and their owning processes
sysctl net.mptcp.enabled # 1 means apps may open MPTCP sockets

Une sortie vide de ss -M signifie qu'il n'y a pas d'écouteur MPTCP. Mais ne vous relâchez pas pour autant : l'équipe Go est explicite, le bug sous-jacent n'est pas propre à MPTCP. C'est un use-after-free générique dans le traitement de la poignée de main ; MPTCP n'est que le chemin qu'on a prouvé de bout en bout.

Le chemin du patch : noyau corrigé, redémarrage, terminé

Le patch est ennuyeux à décrire, car c'est la seule option qui élimine la vulnérabilité au lieu de la redessiner. Les noyaux corrigés ont été publiés en amont les 11 et 15 octobre pour toutes les branches stables maintenues, et le bug remonte à Linux 4.4. Beaucoup de systèmes à longue durée de vie sont donc touchés, y compris des noyaux si anciens qu'en amont plus personne ne s'en occupe.

Le piège, c'est le redémarrage. Une mise à jour du noyau ne sert à rien tant que la machine n'a pas démarré dessus, et c'est là que se situe le vrai coût opérationnel : nœuds Kubernetes vidés, répétitions de bascule, le primaire de base de données que personne ne veut redémarrer en heures ouvrées. C'est pourquoi « il suffit de patcher » est toujours juste comme principe et jamais suffisant comme conseil. Il vous faut un plan de déploiement : d'abord des hôtes canaris, puis les tiers sans état, puis les tiers avec état dans des fenêtres de maintenance. Si vous avez déjà vécu une rotation d'urgence du noyau sur tout un parc, vous connaissez la chanson. Les équipes qui s'en sortent bien sont celles qui ont répété le vidage des nœuds quand rien ne brûlait ; les réflexes d'ingénierie défensive que vous construisez les jours calmes sont ceux qui paient lors d'un 9,8.

Un piège qui mérite d'être nommé : dpkg -l ou rpm -q kernel affichant un paquet corrigé ne signifie rien si le noyau en cours d'exécution est antérieur. uname -r indique ce qui tourne réellement. Sur les systèmes de type RHEL, needs-restarting -r vous dira clairement si un redémarrage est en attente. J'ai relu des rapports post-incident où le parc « patché » était un parc de noyaux installés mais non démarrés. Vérifiez la version en cours d'exécution par rapport au suivi de votre distribution, pas au numéro amont : les noyaux des distributions embarquent des backports sous leur propre versionnement.

La voie de la mitigation : abandonner les options IPv4, désactiver MPTCP

La mitigation intérimaire publiée est une règle nftables qui rejette les paquets TCP IPv4 entrants portant des options IP, la condition déclenchante du chemin vulnérable. Vous pouvez la compléter en désactivant MPTCP (sysctl -w net.mptcp.enabled=0) si vous ne l'utilisez pas. Les deux sont rapides, ne nécessitent pas de redémarrage et se déploient avec votre outil de gestion de configuration en un après-midi. C'est là tout leur attrait.

Maintenant, la partie qui devrait tempérer votre enthousiasme : le bulletin de Red Hat affirme que sa règle « réduit l'exposition à cette vulnérabilité mais ne peut pas l'empêcher complètement ». Relisez cette phrase deux fois. La mitigation réduit la surface d'attaque ; elle ne la ferme pas. Les paquets avec options IP sont rares dans le trafic normal, la plupart des intergiciels les rejettent de toute façon, ce qui est l'une des raisons pour lesquelles l'exploitation sur Internet ouvert est jugée peu probable. Mais « rare » et « impossible » ne sont pas la même chose, et le bug se trouve dans du code générique de poignée de main, pas seulement dans le chemin des options que quelqu'un a eu l'occasion de tester.

Il y a aussi un coût plus subtil : la mitigation crée une fausse impression de clôture. Le ticket passe en « fait, plus ou moins », l'urgence s'évapore du chantier de patch, et six semaines plus tard vous faites toujours tourner un noyau vulnérable derrière un filtre de paquets, avec une mémoire institutionnelle de la raison qui s'estompe vite. J'ai déjà écrit sur ce schéma à propos de la fenêtre des CVE critiques de PHP, où les équipes qui ont simplement mis hors ligne le composant vulnérable s'en sont mieux sorties que celles qui ont empilé des filtres astucieux. Même leçon, autre pile technique.

Patcher ou atténuer : quand chaque option gagne

Voici mon bilan honnête, après des années à prendre cette décision sous pression.

• Un noyau corrigé est disponible pour votre distribution. Le patch gagne sans discussion. Debian, SUSE Enterprise, Oracle UEK et Amazon Linux ont tous livré des correctifs. Aucune mitigation n'est plus astucieuse qu'un correctif amont de quatre lignes. Planifiez les redémarrages, déployez par anneaux, et passez à autre chose.
• Pas encore de noyau corrigé, exposition réelle. Atténuez immédiatement, c'est exactement à cela que servent les mitigations. Ubuntu et RHEL étaient encore « vulnérables » ou « affectés » à la fin octobre. Si vous êtes exposé sur Internet avec un écouteur MPTCP, abandonnez les paquets avec options IP et désactivez MPTCP dès aujourd'hui, tout en suivant le noyau corrigé comme une version bloquante.
• Exposé sur Internet mais derrière une porte d'entrée managée. Votre urgence baisse. La recommandation d'AWS, selon laquelle le trafic passant par leurs load balancers, CloudFront ou API Gateway n'atteint pas vos instances sous forme de TCP brut non fiable, est fondée. Atténuez malgré tout (c'est peu coûteux), et patchez dans un cycle normal plutôt que dans un cycle d'urgence.
• Systèmes à cœur unique ou à file unique. Priorité moindre. La course nécessite un traitement concurrent des paquets sur plusieurs CPU. Les systèmes embarqués et les petites VM gagnent un peu de marge, mais ce sont aussi souvent les machines que personne ne redémarre jamais, alors ne laissez pas « faible priorité » devenir « jamais ».
• Noyaux en fin de vie (amont antérieur à 5.10). La mitigation est votre seule option indépendante de l'amont. C'est le scénario où les mitigations gagnent vraiment, car l'alternative est un backport du fournisseur qui n'arrivera peut-être jamais. C'est aussi un signal fort : la machine elle-même est la vulnérabilité, et la vraie solution est de la remplacer.

Le retard des distributions, le vrai problème

Ce qui devrait vous inquiéter n'est pas le bug, car les correctifs de use-after-free de quatre lignes arrivent dans les noyaux stables chaque mois. C'est que deux des plus grandes distributions serveur au monde, Ubuntu et RHEL, n'avaient toujours pas livré de correctif plus de deux semaines après l'amont, alors qu'Amazon Linux avait patché tous ses noyaux et qu'AlmaLinux, une reconstruction communautaire, avait des noyaux corrigés en test avant même l'amont. La communauté HN l'a remarqué, et elle a raison de s'agacer : ce sont les distributions qui se vendent le plus fort sur la maturité serveur.

Pour les praticiens, la leçon est peu glamour : votre fenêtre d'exposition est définie par le pipeline de backport de votre éditeur, pas par l'amont. Cela impose deux choses. D'abord, connaître les URL de suivi de votre distribution et les surveiller réellement, car cette CVE est restée à « Received » sur NVD sans analyse alors que le CNA du noyau, Red Hat et les distributions avaient tous des pages détaillées. Ensuite, traiter la réactivité de la distribution comme un critère de choix. Amazon Linux vient de démontrer un pipeline de correctifs noyau nettement plus rapide que les deux acteurs historiques. Cela ne fera pas le poids dans une présentation commerciale, mais cela compte le week-end d'Halloween, quand tombe un 9,8.

L'exploit écrit par une IA change l'horloge

La ligne la plus lourde de conséquences dans la divulgation passe facilement inaperçue : Anthropic indique que son modèle Claude a produit un exploit root distant fonctionnel, après une consigne initiale et en moins d'une heure de temps machine pour passer d'une fuite de pointeur noyau à un shell root. Ils ne l'ont pas publié, et les sceptiques de HN se sont régalés du ton « faites-moi confiance ». Juste. Mais même en retirant la part de marketing, la tendance est claire : le délai entre « le diff arrive dans l'arbre stable » et « un exploit fonctionnel existe » est en train de s'effondrer, car le goulot d'étranglement de l'écriture d'exploits n'a jamais été le bug. C'était l'humain capable de lire le diff et de faire le heap grooming.

Cela compresse la fenêtre de décision entre patcher et atténuer. Quand le développement d'un exploit prenait des semaines, « atténuer maintenant, patcher à la prochaine fenêtre de maintenance » se défendait. Quand un modèle peut sortir un PoC pendant la nuit à partir d'un commit public, votre phase de mitigation doit se mesurer en heures, et votre phase de patch en jours. Le correctif de quatre lignes est public. N'importe qui peut l'étudier. Partez du principe que l'exploit l'est aussi.

Ma recommandation

Patchez. N'atténuez qu'en pont, et donnez une date d'expiration à ce pont. Concrètement : si votre distribution dispose d'un noyau corrigé, commencez à le déployer maintenant et vérifiez uname -r après chaque redémarrage. Si vous êtes sur Ubuntu ou RHEL, déployez le rejet des options IP et désactivez MPTCP dès aujourd'hui, puis traitez le correctif noyau manquant comme une dépendance bloquante : consultez le suivi chaque jour, pas chaque semaine. Priorisez ce qui est exposé sur Internet avec un écouteur MPTCP, puis tout ce qui accepte du TCP entrant, c'est-à-dire presque tout. Les conteneurs ne vous sauveront pas : ils partagent le noyau de l'hôte, donc patchez les nœuds.

La leçon de fond, que ce bug nous rappelle tous les quelques années sous un nouveau numéro de CVE : les mitigations achètent du temps, mais seuls les patchs referment les trous, et le temps que les mitigations achètent se raccourcit. Construisez dès maintenant la capacité à déployer des noyaux vite et sans risque, avant d'en avoir besoin, car le prochain correctif de quatre lignes attend déjà dans la file de quelqu'un.