Ce que décrit la fiche, fonction par fonction
La fiche Ubuntu décrit un défaut de gestion mémoire dans l'établissement des connexions TCP en IPv4. Quand un client envoie un SYN, le noyau crée une requête de connexion ; à la fin de la poignée de main, tcp_v4_syn_recv_sock() crée la socket fille. Selon la fiche, cette fonction transmet à la socket fille les options IP de la requête sans les copier. Si un SYN retransmis est traité au même moment sur un autre processeur, le noyau peut relire ces options déjà libérées en construisant le SYNACK : c'est l'utilisation après libération, dans ip_options_build().
La fiche signale une course analogue lors de la migration des requêtes entre sockets, quand net.ipv4.tcp_migrate_req=1 ou qu'un programme BPF_SK_REUSEPORT_SELECT_OR_MIGRATE est en place. Le correctif décrit retarde la libération de la mémoire jusqu'à la fin d'une période de grâce RCU, avec kfree_rcu(), dans inet_sock_destruct() et tcp_v4_reqsk_destructor(). IPv6 n'est pas touché par le premier défaut ; la fiche indique qu'un défaut de migration semblable existe de ce côté et sera traité séparément. Retenez aussi ce qu'elle ne dit pas : l'exploitabilité à distance n'est pas démontrée publiquement dans les fiches lues.
Deux scores, deux émetteurs : 9,8 et 8,1
Les deux chiffres ne se contredisent pas, ils décrivent des choses différentes. Ubuntu affiche une priorité High et un score CVSS 3 de 9,8, qualifié de Critical. Red Hat publie un CVSS v3.1 de 8,1, avec le vecteur CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:H. La page Red Hat donne aussi, pour comparaison, la valeur de cve.org : 9,8 avec AC:L. Seule la complexité d'attaque change : faible (AC:L) d'un côté, élevée (AC:H) de l'autre.
Le 8,1 de Red Hat traduit une course à timing serré, où l'attaquant doit faire coïncider deux traitements sur deux processeurs ; sa description parle d'abord d'un plantage, avec une corruption de mémoire possible. La page précise que ces scores sont préliminaires et sujets à révision. Ne retenez donc pas un chiffre unique : 9,8 selon Ubuntu, 8,1 selon Red Hat. Dans les vecteurs publiés par Red Hat et cve.org, la faille est atteignable par le réseau sans authentification (AV:N, PR:N), ce qui suffit à la traiter sérieusement sans la présenter comme une attaque en cours : aucune des deux fiches lues n'en signale.
L'état publié au 30 octobre 2026
Faites défiler le tableau
| Source ou version | État lu sur la fiche | Ce que cela change pour vous |
|---|---|---|
| Ubuntu 24.04 LTS (noble) | Vulnerable, correctif en cours ; version listée 6.8.0-149.149 | Aucun noyau corrigé à installer pour l'instant |
| Ubuntu 22.04 LTS (jammy) | Vulnerable, correctif en cours ; version listée 5.15.0-203.213 | Aucun noyau corrigé à installer pour l'instant |
| Ubuntu 26.04 LTS | Vulnerable, correctif en cours ; version listée 7.0.0-43.43 | Aucun noyau corrigé à installer pour l'instant |
| Ubuntu 20.04 LTS (focal) | Aucune version listée ; statut à relire sur la fiche | Rouvrir la fiche avant toute conclusion |
| Red Hat | CVSS v3.1 8,1, aucune mitigation proposée, aucun paquet corrigé listé, Bugzilla 2553390 | Pas de contournement officiel ; suivre le ticket |
| Debian, AlmaLinux, Rocky et autres | Non lu pour cet article | Lire l'avis de votre éditeur, sans déduire depuis Ubuntu |
| Un numéro de version sur une fiche | Ce n'est pas une version corrigée tant que le statut n'est pas passé à corrigé | Ne comparez `uname -r` à ce numéro qu'après ce changement de statut |
Un noyau installé n'est pas un noyau en cours
Un apt upgrade ou un dnf update dépose un nouveau noyau dans /boot, mais le système continue d'exécuter celui chargé au dernier démarrage, jusqu'au redémarrage. uname -r répond à la seule question qui compte ici : quel noyau tourne maintenant. La liste des paquets répond à une autre : quels noyaux dorment sur le disque. Quand le correctif sortira, un VPS peut donc afficher « à jour » dans son gestionnaire de paquets et rester vulnérable des semaines.
L'inverse vaut aujourd'hui : installer les mises à jour du jour ne corrige pas cette CVE, puisque les fiches ne listent pas de noyau corrigé. Les conteneurs Docker ne changent rien, ils partagent le noyau de la machine. Sur une machine virtuelle complète, ce noyau est le vôtre ; sur un VPS de type conteneur, c'est celui de l'hôte, qu'il faut alors demander à l'hébergeur. La procédure de redémarrage elle-même est détaillée dans le guide PwnEscape et Vghost lié sous cet article : inutile de la répéter ici.
Vérifier votre VPS en dix minutes
Relever le noyau en cours
uname -rcat /proc/version
Notez la chaîne complète, suffixe compris (-generic,-aws,-kvm,el9…). C'est elle que vous comparerez à la fiche de votre distribution, et le suffixe indique la variante de noyau à chercher.Lister les noyaux installés et le redémarrage en attente
Debian, Ubuntu :
dpkg -l 'linux-image*' | grep '^ii'puisls /var/run/reboot-required
RHEL, AlmaLinux, Rocky :rpm -q kernelpuissudo needs-restarting -r
Si le noyau le plus récent installé diffère de celui deuname -r, un redémarrage est en attente.Chercher un correctif publié
Debian, Ubuntu :
sudo apt updatepuisapt list --upgradable 'linux-image*'
RHEL, AlmaLinux, Rocky :sudo dnf updateinfo list --cve CVE-2026-98432puissudo dnf check-update kernel
Une liste vide ne prouve pas que vous êtes protégé : elle dit seulement que votre dépôt ne propose rien pour l'instant.Lire ce que le paquet candidat annonce
Debian, Ubuntu :
apt changelog <paquet-listé-à-l-étape-précédente> | grep -n 'CVE-2026-98432'
RHEL, AlmaLinux, Rocky :sudo dnf updateinfo info --cve CVE-2026-98432
Si l'identifiant apparaît, le paquet annonce le correctif ; relevez alors son numéro de version et confirmez-le sur la fiche de votre distribution avant de conclure.Lire l'exposition réseau
sudo ss -4tlnpsysctl net.ipv4.tcp_migrate_req
La première commande liste les ports TCP IPv4 en écoute, donc les seuls endroits où une poignée de main TCP arrive ; c'est notre lecture de la fiche, pas une affirmation de celle-ci. La seconde affiche l'état du réglage de migration (0ou1). Ce réglage ne ferme pas la faille : le premier défaut décrit existe sans lui.Rouvrir la fiche le jour de la décision
Ouvrez la fiche de votre distribution, relevez le statut de votre variante de noyau et la date de dernière mise à jour affichée. Notez-les avec la date de lecture : ces pages bougent, et un état lu il y a trois jours n'est pas l'état d'aujourd'hui.
Agir sans correctif confirmé
- Fermer ce qui n'a pas à être joint — chaque port TCP IPv4 ouvert à tout Internet est une entrée possible. Restreignez SSH, bases de données et administration aux adresses utiles avec
ufwoufirewalld. Cela réduit la surface, sans corriger un port public comme le 443. - Ne pas compter sur un contournement — Red Hat n'en propose aucun, et la partie lue de la fiche Ubuntu n'en liste pas. Passer
net.ipv4.tcp_migrate_reqà0ne couvre pas le premier défaut décrit. - Préparer la fenêtre de redémarrage — choisissez le créneau, prévenez les utilisateurs, vérifiez que vos services redémarrent seuls (
systemctl is-enabled <service>) et faites une sauvegarde ou un instantané avant. - Détecter le correctif dès sa publication — lancez chaque jour
apt list --upgradable 'linux-image*'oudnf check-update kernel, ou relisez la fiche. Selon sa configuration, la mise à jour automatique installe le noyau sans redémarrer. - Garder un accès de secours — repérez la console d'urgence de votre hébergeur avant le redémarrage, pas pendant : un noyau qui ne remonte pas se règle depuis là.
- Surveiller les plantages — Red Hat décrit surtout un plantage.
journalctl -k -p err --since '7 days ago'etlast -x rebootmontrent un redémarrage ou un message noyau inhabituel à rapprocher de la date de publication.
Livepatch : une option, à une condition
Un correctif à chaud applique un patch au noyau en cours, sans redémarrage. Il n'existe qu'une fois produit par l'éditeur ou par le fournisseur du service, et il ne couvre que les CVE que celui-ci a traitées. Avec le service Livepatch de Canonical, canonical-livepatch status --verbose indique les correctifs appliqués ; sur d'autres distributions, des services tiers comme KernelCare jouent ce rôle. La règle est la même partout : tant que l'identifiant CVE-2026-98432 n'apparaît pas dans la liste des correctifs appliqués, vous n'êtes pas couvert, même si le service est affiché comme actif.
Aucune des fiches lues ne mentionne de livepatch pour cette CVE à la date de consultation. Et un livepatch ne dispense pas du noyau suivant : prévoyez quand même le redémarrage vers la version corrigée, au créneau que vous aurez choisi.
Écrire la date, pas seulement l'état
Dans votre carnet d'exploitation, notez pour chaque serveur le noyau en cours, le statut lu sur la fiche et la date de lecture. Dans ce guide, l'état décrit est celui du 30 octobre 2026 ; il a pu changer quand vous le lisez. Ce guide est fourni tel quel : l'administration de votre serveur reste de votre ressort, sans prise en charge de notre part.
Le jour où un noyau corrigé apparaît
Lisez d'abord la fiche : le statut de votre variante doit être passé à corrigé et indiquer un numéro de version. La fiche Ubuntu ne liste pas un seul paquet mais plusieurs (linux, linux-aws, linux-azure, linux-gcp…) : suivez la ligne qui correspond au suffixe affiché par uname -r, pas la ligne du paquet linux par défaut.
Installez ensuite avec sudo apt upgrade (Debian, Ubuntu) ou sudo dnf upgrade kernel (RHEL, AlmaLinux, Rocky), redémarrez avec sudo reboot, puis vérifiez avec uname -r que la chaîne en cours correspond au noyau corrigé annoncé. Si elle correspond encore à l'ancien, le redémarrage n'a pas basculé sur le nouveau noyau : regardez l'entrée de démarrage par défaut avant de déclarer le serveur corrigé. Inscrivez enfin le numéro installé dans votre carnet.
La documentation officielle
Fiche Ubuntu de CVE-2026-98432 (publiée le 15 octobre 2026, mise à jour le 29 octobre 2026): https://ubuntu.com/security/CVE-2026-98432
Fiche Red Hat de CVE-2026-98432 (CVSS 8,1, Bugzilla 2553390): https://access.redhat.com/security/cve/CVE-2026-98432
Les deux fiches ont été consultées le 30 octobre 2026 ; elles peuvent avoir changé depuis.
