CVE-2026-98432 : comprendre la faille Linux et protéger ses serveurs

Un serveur peut être exposé avant même qu’un utilisateur se connecte. La faille CVE-2026-98432 touche le traitement des connexions TCP IPv4 dans le noyau Linux. Voici comment comprendre le problème et vérifier votre protection. Pour apprendre à administrer votre environnement, notre formation Linux et Bash vous accompagne dans la prise en main du système et du terminal.

Informations vérifiées le 2 novembre 2026 à partir des bulletins officiels cités dans l’article. La disponibilité des correctifs peut évoluer selon la distribution et la variante du noyau.

Références pour ce point de situation : fiche Canonical, suivi Debian et bulletin AWS.

Que se passe-t-il dans le noyau Linux ?

Le noyau gère notamment les connexions réseau et la mémoire du système. Lorsqu’un client ouvre une connexion TCP, plusieurs opérations peuvent se dérouler en parallèle sur différents cœurs du processeur.

Ici, une course entre ces opérations peut libérer la mémoire contenant des options IPv4 alors qu’un autre traitement l’utilise encore. C’est une erreur de type use-after-free, littéralement une utilisation après libération. Le correctif retarde cette libération jusqu’à la fin des lectures concernées, grâce au mécanisme RCU du noyau. La description technique figure dans l’annonce de l’équipe de sécurité Linux.

Selon AWS, les conséquences possibles comprennent un crash du noyau, une divulgation de mémoire ou une corruption mémoire. Des chercheurs ont démontré une exécution de code à distance sans authentification sur des machines avec un service en écoute Multipath TCP (MPTCP). Cette précision compte : la démonstration ne signifie pas que tous les serveurs Linux peuvent être compromis de la même façon. Source : bulletin AWS du 30 octobre, actualisé le 1er novembre 2026.

Quels serveurs vérifier en priorité ?

Commencez par les machines dont le noyau est vulnérable et qui acceptent des connexions TCP IPv4 entrantes. Red Hat souligne que l’attaque ne nécessite ni privilège préalable ni interaction de l’utilisateur. Un mot de passe solide sur votre application ne corrige donc pas cette erreur de mémoire dans le noyau. Source : bulletin de sécurité Red Hat.

Reconstruire une image Docker ne remplace pas le noyau de son hôte. Pour les services managés, suivez les instructions du fournisseur : le bulletin AWS distingue, par exemple, les instances autogérées, les nœuds de conteneurs et les services dont l’infrastructure est prise en charge par AWS.

Comment appliquer le correctif ?

1. Identifier votre distribution et votre noyau actif.
2. Installer le paquet annoncé comme corrigé par l’éditeur.
3. Activer ce noyau en redémarrant, puis vérifier le résultat.

Commencez par relever ces informations :

cat /etc/os-release
uname -r

Choisissez ensuite le métapaquet correspondant au noyau déjà utilisé. Les exemples ci-dessous concernent deux configurations courantes. Ils s’appliquent lorsque le correctif est disponible dans les dépôts de sécurité configurés sur la machine.

Sur Ubuntu avec le noyau generic standard

sudo apt update
sudo apt install --only-upgrade linux-generic

Les variantes HWE, AWS, Azure ou GCP utilisent d’autres métapaquets. Gardez celui de votre environnement et vérifiez son statut dans la fiche de la CVE chez Canonical. Au moment de cette vérification, plusieurs variantes sont encore en cours de correction.

Sur Debian avec le noyau standard amd64

sudo apt update
sudo apt install --only-upgrade linux-image-amd64

Debian utilise ici linux-image-amd64, pas linux-generic. Adaptez le paquet à votre architecture et à votre variante. Le suivi Debian référence notamment les versions corrigées 6.1.190-1 pour Bookworm et 6.12.113-1 pour Trixie. Ces numéros désignent des versions de paquets sources, à rapprocher de votre paquet binaire.

APT actualise d’abord l’index, puis installe les paquets demandés et leurs dépendances. Consultez les changements proposés avant de les accepter. Références : gestion des logiciels sur Ubuntu et mise à jour du noyau dans les notes Debian.

Redémarrer sur le nouveau noyau

Une fois le noyau corrigé installé et votre fenêtre de maintenance prête, redémarrez le serveur :

sudo reboot

Le redémarrage coupe les connexions en cours. Sur une flotte, procédez machine par machine selon votre procédure de disponibilité.

Livepatch permet-il d’éviter le redémarrage ?

Seulement si un patch à chaud couvrant cette CVE existe pour votre noyau et a été appliqué avec succès. Le simple fait d’avoir activé Canonical Livepatch ne constitue pas cette preuve.

Sur une machine où le service est déjà configuré, vous pouvez demander une actualisation, puis examiner son état :

sudo canonical-livepatch refresh
canonical-livepatch status --verbose

Vérifiez que CVE-2026-98432 figure parmi les vulnérabilités effectivement corrigées dans le noyau en cours d’exécution. Le mode détaillé distingue aussi des correctifs qui ne prendront effet qu’au prochain démarrage. Appuyez-vous sur la documentation du statut Livepatch et sur l’avis LSN associé au patch. La liste des avis Canonical permet de retrouver ces notices.

Si la couverture de cette CVE n’est pas confirmée, restez sur la procédure noyau corrigé puis redémarrage. Aucune disponibilité générale d’un livepatch pour cette faille n’est présumée dans cet article.

Comment vérifier que la protection est active ?

Après la reconnexion, relevez le noyau réellement chargé et la version de son paquet :

uname -r
dpkg-query -W -f='${Package}\t${Version}\n' "linux-image-$(uname -r)"

Comparez cette version avec le bulletin de votre distribution pour votre variante exacte. Le changelog du paquet peut également mentionner CVE-2026-98432 ou le correctif ipv4: free inet_opt and ireq_opt after an RCU grace period. Un numéro de noyau plus ancien en apparence peut inclure un correctif rétroporté : le statut du paquet chez l’éditeur reste la référence.

Et si le correctif n’est pas encore disponible ?

Limitez les accès réseau inutiles et suivez les mesures temporaires publiées pour votre environnement. Red Hat propose notamment un filtrage des paquets IPv4 TCP contenant des options IP, à tester selon vos contraintes réseau. Son bulletin précise que cette mesure ne garantit pas une protection complète. Appliquez le correctif dès sa disponibilité. Voir la procédure officielle Red Hat.

Questions fréquentes

Pour mieux comprendre ces opérations et gagner en autonomie dans le terminal, retrouvez notre formation Linux et Bash.