CVE-2026-98432 : vulnérabilité TCP du noyau Linux — de quoi s’agit-il et que faire sur votre VPS ou serveur dédié

Au 29 octobre 2026, la vulnérabilité CVE-2026-98432 du noyau Linux est corrigée dans les branches stables officielles et dans Debian, mais Ubuntu, Red Hat, AlmaLinux, Rocky et SUSE 15 n’ont pas encore publié de noyau corrigé. Au moment de la publication, aucun exploit public n’est connu. Si vous avez un VPS ou un serveur dédié Linux chez Fusiora, c’est vous qui gérez son noyau : cet article explique ce qui s’est passé et les étapes à suivre.

Ce qui s’est passé, en termes simples

Lorsque quelqu’un ouvre une connexion TCP vers votre serveur, le noyau conserve temporairement certaines informations du premier paquet (le SYN). Si ce paquet contient des options IPv4 (des champs facultatifs de l’en-tête IP, comme Record Route ou Timestamp, que le trafic normal n’utilise presque jamais), le noyau peut libérer cette mémoire alors qu’une autre partie du système l’utilise encore. C’est ce qu’on appelle un use-after-free.

En pratique, le résultat le plus probable est que le serveur plante et redémarre (déni de service). Les sources officielles ne s’accordent pas sur la gravité : la fiche du CVE mentionne aussi une possible divulgation du contenu de la mémoire du noyau à l’attaquant et une corruption de mémoire, tandis que Red Hat estime qu’un plantage est le plus probable et qu’aucun impact sur la confidentialité ou l’intégrité n’a été démontré.

Détail technique en bref

• Correctif : commit e3f33b0a1d89 « ipv4: free inet_opt and ireq_opt after an RCU grace period » (Eric Dumazet, 1er octobre 2026), inclus dans Linux 7.3. Il remplace deux appels kfree() par kfree_rcu() dans net/ipv4/af_inet.c et net/ipv4/tcp_ipv4.c.
• Cause : tcp_v4_syn_recv_sock() transmet les options IP de la requête au socket enfant sans les copier. Si un SYN retransmis arrive au même moment, un autre CPU peut être en train d’envoyer un SYN-ACK avec ces options pendant que le socket enfant est détruit et les libère.
• Seconde variante : uniquement si la migration des requêtes TCP est activée (net.ipv4.tcp_migrate_req=1, qui vaut 0 par défaut, ou un programme BPF reuseport qui migre les requêtes).
• Vecteur : distant et sans authentification, pendant la poignée de main, avant toute intervention de l’application. Il faut un service TCP à l’écoute en IPv4, un SYN portant des options IP et gagner une situation de concurrence (race condition). Le CNA juge la complexité faible ; Red Hat et SUSE la jugent élevée.
• IPv6 : non concerné par la faille principale. Inutile de désactiver IPv6.

Qui est concerné ?

• VPS Linux : chaque VPS démarre son propre noyau, que vous installez et mettez à jour depuis le système d’exploitation. Si votre VPS exécute un noyau vulnérable, vous devez le mettre à jour et redémarrer.
• Serveurs dédiés Linux : même chose. Vous disposez d’un accès root complet et le noyau relève de votre responsabilité.
• Conteneurs (Docker, LXC, Podman) sur votre serveur : ils partagent le noyau de l’hôte ; ils sont donc protégés une fois le noyau de ce serveur mis à jour.
• Non concernés : Windows Server et FreeBSD, car ils n’utilisent pas le noyau Linux.

État des correctifs au 29 octobre 2026

Noyaux officiels (kernel.org). Ces versions, ou toute version ultérieure de la même branche, incluent déjà le correctif :

La fiche du CVE ne mentionne aucune branche 4.x ou 5.4 corrigée (toutes deux ne sont plus officiellement maintenues).

Par distribution. Attention : chaque distribution numérote ses noyaux à sa manière ; ce qui compte, c’est le paquet corrigé de chacune :

Sur les distributions qui livrent des noyaux récents issus des branches officielles (par exemple Fedora, Arch ou Alpine), comparez votre version avec le tableau kernel.org. Si vous utilisez Debian 10 ou 11 ou un autre système qui n’est plus maintenu, ne comptez pas sur un correctif : prévoyez de passer à une version maintenue (sur un VPS, depuis le panel, Manage → Rebuild ; attention, la réinstallation efface toutes les données ; sur un serveur dédié, ouvrez un ticket). CentOS 7 utilise le noyau de RHEL 7, que Red Hat déclare non concerné par ce CVE, mais il ne reçoit plus de mises à jour de sécurité : une migration reste conseillée.

Étapes pour les clients

Connectez-vous en SSH (guide) et exécutez les commandes en root ou avec sudo.

1. Vérifier quel noyau est en cours d’exécution

uname -r

Sous Debian, la version exacte du paquet apparaît à la fin de :

uname -v

Par exemple, « Debian 6.12.113-1 » ou plus récent sous Debian 13 signifie que vous avez déjà la version corrigée. Sous Ubuntu, RHEL et leurs dérivés, le numéro de uname -r est propre à la distribution : comparez-le avec son avis de sécurité, pas avec le tableau kernel.org.

2. Faire une sauvegarde avant toute modification

Si votre offre inclut des snapshots, prenez-en un avant la mise à jour. Sinon, copiez hors du serveur tout ce que vous ne pouvez pas vous permettre de perdre. Mettre à jour le noyau est une opération courante, mais c’est au redémarrage qu’un problème existant peut se révéler.

3. Mettre à jour le système

Debian et Ubuntu :

apt update && apt full-upgrade

Sous Debian 12, si vous utilisez le noyau 6.12 du paquet linux-6.12 (DLA-4850-1), full-upgrade le met également à jour. Pour vérifier les paquets de noyau installés :

dpkg -l 'linux-image*'

AlmaLinux, Rocky, RHEL, Fedora, Oracle et CloudLinux :

dnf upgrade --refresh

rpm -q kernel

SUSE et openSUSE :

zypper refresh && zypper patch

Arch :

pacman -Syu

Alpine :

apk update && apk upgrade

Sous Ubuntu, RHEL, AlmaLinux et Rocky, il n’existe pas encore de noyau corrigé au 29 octobre ; pour Oracle Linux (noyau UEK) et CloudLinux, consultez l’avis de votre éditeur. Il reste utile d’appliquer les mises à jour en attente, et vous devrez répéter cette étape dès que votre distribution publiera son avis (voir l’étape 8) ; en attendant, appliquez la mesure d’atténuation de l’étape 5.

4. Redémarrer et vérifier la nouvelle version

Le nouveau noyau n’est utilisé qu’après un redémarrage :

reboot

Une fois le serveur revenu, relancez uname -r (et uname -v sous Debian) et comparez le résultat avec le paquet corrigé de votre distribution (tableau « Par distribution »), ou avec le tableau kernel.org si vous utilisez un noyau officiel. Si le serveur ne répond plus en SSH après le redémarrage :

• VPS : connectez-vous au panel vps.fusiora.com et ouvrez la console VNC (onglet Options → Browser VNC ; si vous ne voyez pas le bouton, cliquez d’abord sur Enable VNC).
• Serveur dédié : utilisez la console distante IPMI/KVM.
• Dans le menu GRUB (sous Debian et Ubuntu, dans « Advanced options » ; si le menu n’apparaît pas, maintenez Shift ou appuyez sur Échap au démarrage), vous pouvez choisir le noyau précédent le temps d’analyser le problème.

5. Si votre distribution n’a pas encore de correctif : atténuation temporaire

La faille n’est déclenchée que par des SYN TCP IPv4 portant des options IP, très rares dans le trafic légitime. Vous pouvez rejeter ces paquets avec nftables. La règle laisse passer les SYN normaux et n’affecte ni IPv6 ni les autres protocoles. Si votre serveur relaie du trafic (par exemple comme routeur ou passerelle VPN), elle filtre aussi ces SYN en transit. Elle ne remplace pas le correctif.

Si vous n’avez pas la commande nft, installez-la avec apt install nftables ou dnf install nftables. La règle se trouve dans sa propre table, qui cohabite avec ufw, firewalld et Docker :

nft add table inet cve_2026_98432

nft add chain inet cve_2026_98432 pre '{ type filter hook prerouting priority -300; policy accept; }'

nft add rule inet cve_2026_98432 pre 'ip hdrlength > 5 tcp flags & (syn | ack) == syn counter drop'

Pour la vérifier (le compteur indique combien de paquets ont été rejetés) :

nft list table inet cve_2026_98432

Pour la supprimer :

nft delete table inet cve_2026_98432

Ajoutée de cette façon, la règle ne survit pas à un redémarrage. Ne l’ajoutez pas à /etc/nftables.conf et n’activez pas nftables.service pour cela : selon la distribution, cette configuration vide toutes les règles du système, y compris celles de Docker ou d’ufw. Si vous avez besoin qu’elle persiste après un redémarrage, enregistrez-la dans son propre fichier, /etc/cve-2026-98432.nft :

table inet cve_2026_98432 {
  chain pre {
    type filter hook prerouting priority -300; policy accept;
    ip hdrlength > 5 tcp flags & (syn | ack) == syn counter drop
  }
}

Puis chargez-la avec son propre service, /etc/systemd/system/cve-2026-98432.service :

[Unit]
Description=Mitigation CVE-2026-98432

[Service]
Type=oneshot
RemainAfterExit=yes
ExecStart=/usr/sbin/nft -f /etc/cve-2026-98432.nft
ExecStop=/usr/sbin/nft delete table inet cve_2026_98432

[Install]
WantedBy=multi-user.target

Supprimez d’abord la règle manuelle si vous l’avez ajoutée (nft delete table inet cve_2026_98432), pour éviter de la dupliquer. Ensuite :

systemctl daemon-reload && systemctl enable --now cve-2026-98432.service

Une fois sur le noyau corrigé, désactivez-la avec systemctl disable --now cve-2026-98432.service.

Sur les systèmes plus anciens sans nftables, l’équivalent iptables est :

iptables -t raw -I PREROUTING -p tcp --syn -m u32 ! --u32 "0>>22&0x3C=20" -j DROP

Comme la règle nft ajoutée à la main, celle-ci ne survit pas à un redémarrage.

Vérifiez aussi que la variante liée à la migration est désactivée (la commande doit renvoyer 0, la valeur par défaut) :

sysctl net.ipv4.tcp_migrate_req

Si elle indique que la clé n’existe pas, votre noyau ne dispose pas de cette fonctionnalité et cette variante ne s’applique pas.

Ne filtrez pas tous les paquets portant des options IP : IGMP les utilise et vous casseriez le multicast. La règle ci-dessus est volontairement limitée aux SYN TCP.

6. Livepatch : uniquement là où il existe

Au 29 octobre 2026, nous n’avons trouvé aucun correctif à chaud (livepatch) pour ce CVE chez Canonical, Red Hat ou SUSE. SUSE a publié un noyau corrigé pour 16.0 (6.12.0-160000.40.1), qui nécessite un redémarrage. Sans correctif à chaud, la solution consiste à mettre à jour le noyau et à redémarrer.

7. Revoir ce que vous exposez sur Internet

La faille nécessite un service TCP à l’écoute en IPv4. C’est le bon moment pour fermer dans votre pare-feu (ufw ou firewalld) les ports dont vous n’avez pas besoin et pour restreindre les ports d’administration à vos propres IP. Notre guide Configurer votre premier VPS couvre la configuration de base du pare-feu.

8. Suivre les avis et demander de l’aide si besoin

Suivez la page CVE de votre distribution (liens ci-dessous) et, lorsque le noyau corrigé paraît, répétez les étapes 3 et 4. Si vous avez des questions ou si quelque chose ne démarre plus après la mise à jour, ouvrez un ticket en indiquant votre service et la sortie de uname -r.

Questions fréquentes

Fusiora met-il à jour le noyau de mon VPS ou serveur dédié ?

Non, sauf si vous avez souscrit un service infogéré ; dans ce cas, renseignez-vous auprès du support. Sur un VPS ou serveur dédié standard, vous disposez d’un accès root complet et vous gérez le système d’exploitation, noyau compris. Si vous souhaitez de l’aide pour les étapes, ouvrez un ticket.

Suffit-il de mettre à jour les paquets ?

Non. Tant que vous n’avez pas redémarré, l’ancien noyau reste en cours d’exécution. Vérifiez avec uname -r que vous êtes sur la nouvelle version.

Dois-je désactiver IPv6 ?

Non. IPv6 n’est pas concerné par la faille principale.

La règle nftables peut-elle casser quelque chose ?

Elle rejette uniquement les SYN TCP IPv4 portant des options IP, très rares dans le trafic légitime. Elle ne touche ni IPv6 ni les autres protocoles, et une seule commande suffit à la supprimer.

Mon Windows Server est-il concerné ?

Non. Il s’agit d’une vulnérabilité du noyau Linux.

La faille est-elle exploitée ?

Au moment de la publication, aucun exploit public n’est connu et le CVE ne figure pas au catalogue KEV de la CISA. Nous mettrons cet article à jour si cela change.

---

Sources

• CVE.org : fiche officielle du CNA Linux, publiée le 2026-10-15 et mise à jour le 2026-10-24
• NVD : entrée du CVE avec le score du CNA (consulté le 2026-10-29)
• Ubuntu : état par version, priorité High (mis à jour le 2026-10-28)
• Debian Security Tracker : paquets corrigés, DSA-6568-1, DLA-4841-1 et DLA-4850-1 (consulté le 2026-10-29)
• Red Hat : classement Moderate et statut « Fix deferred » (consulté le 2026-10-29)
• SUSE : état par produit (consulté le 2026-10-29)
• Commit du correctif Linux : « ipv4: free inet_opt and ireq_opt after an RCU grace period » (2026-10-01)
• kernel.org : versions stables actuelles (consulté le 2026-10-29)
• CISA KEV : catalogue des vulnérabilités exploitées, sans ce CVE (consulté le 2026-10-29)