Faille du noyau Linux CVE-2026-98432 : blocage temporaire et application du correctif du noyau

Environnement de testFamille RHELAlmaLinux 9.8LightsailNoyau 5.14.0-687.55.1.el9_8 → 5.14.0-687.64.1.el9_8Vérifié le 2026-11-03
Les chaînes de version et le numéro de port SSH sont des valeurs d'exemple ; seul le noyau corrigé 5.14.0-687.64.1.el9_8 est une valeur tirée de l'annonce d'AlmaLinux

CVE-2026-98432 est une vulnérabilité du noyau Linux dans laquelle le code du noyau qui accepte les connexions TCP IPv4 relit une mémoire déjà libérée ; l'équipe CVE du noyau Linux l'a classée Critical. Comme cette faille peut être attaquée à distance sans authentification, nous avons mis à jour un serveur Lightsail sous AlmaLinux 9.8 avec Nginx et Apache vers les paquets du noyau corrigé, l'avons redémarré, puis avons vérifié le correctif à partir de la version du noyau en cours d'exécution.

1️⃣ Faille du noyau Linux CVE-2026-98432 : fonctionnement et portée

Lorsqu'une demande de connexion TCP (SYN) arrive avec des options IPv4, le noyau conserve une copie de ces options avec la connexion en attente afin de les renvoyer dans sa réponse (SYN-ACK). Une fois la connexion établie, cette copie est transmise telle quelle au socket de la nouvelle connexion, sans être dupliquée.

Si, entre-temps, le client renvoie le SYN, un autre CPU peut être en train de construire un SYN-ACK avec les mêmes options. Si la nouvelle connexion se ferme alors et que le noyau libère aussitôt la mémoire des options, le code qui construisait le SYN-ACK lit une mémoire déjà libérée : c'est un use-after-free.

Ce code s'exécute pendant que le noyau traite la demande de connexion, avant même que l'application ne voie la connexion. C'est pourquoi, quel que soit le service qui a ouvert le port, s'il écoute en TCP IPv4, une attaque peut l'atteindre à distance sans identifiants, et le score est de 9.8 selon CVSS 3.1.

La faille existe depuis Linux 4.4, si bien que la plupart des serveurs Linux sont concernés. Parmi les blueprints Lightsail, le guide d'AWS cite AlmaLinux 9, CentOS Stream 9, Debian, openSUSE Leap, Ubuntu, Amazon Linux 2 et Amazon Linux 2023. L'annonce d'AlmaLinux cite les versions 8, 9 et 10, et les blueprints d'applications de Lightsail comme WordPress et LAMP tournent aussi sur Debian ou Ubuntu : ils sont donc également concernés.

FreeBSD et Windows Server, qui n'utilisent pas le noyau Linux, ne sont pas concernés.

Les serveurs dont MPTCP (Multipath TCP) est désactivé ont eux aussi besoin du correctif. L'attaque publiée visait des serveurs avec un écouteur MPTCP ouvert, mais la faille elle-même se trouve dans le code TCP IPv4 ordinaire ; l'annonce d'AlmaLinux indique donc que les systèmes sans MPTCP doivent aussi être corrigés.

Le noyau corrigé ne libère la mémoire des options qu'après une période de grâce RCU (grace period), si bien que la mémoire reste en place tant qu'un autre CPU lit les options pour construire un SYN-ACK.

🧩 CVE-2026-98432 use-after-free 흐름
설명 다이어그램
🔍 단계
🌐 클라이언트
📨SYN + IPv4 옵션
🔁SYN 다시 보냄
➜
🐧 커널
🧾IPv4 옵션 사본대기 중인 연결과 함께 보관복제 없이 새 연결의 소켓으로 넘어감새 연결이 닫히며 곧바로 해제RCU 유예 시간이 지난 뒤 해제
⚙️CPU 1새 연결을 맡음새 연결을 닫으며 옵션 해제새 연결을 닫고 해제는 미룸
⚙️CPU 2같은 옵션으로 SYN-ACK 만드는 중해제된 메모리를 읽음읽기를 마친 뒤 해제됨
SYN에 붙은 IPv4 옵션 사본을 대기 중인 연결에 보관합니다.
사본이 새 소켓으로 넘어간 사이, CPU 2가 같은 옵션으로 SYN-ACK를 만듭니다.
CPU 1이 연결을 닫으며 옵션을 해제하고, CPU 2는 해제된 메모리를 읽습니다.
해제를 RCU 유예 시간 뒤로 미뤄, CPU 2가 다 읽은 뒤에 해제합니다.

2️⃣ Vérifier la version du noyau Linux : le noyau est-il corrigé ?

La nécessité du correctif dépend de la version du noyau en cours d'exécution ; avant la mise à jour, nous avons donc d'abord vérifié la distribution et la version du noyau.

cat /etc/os-release
NAME="AlmaLinux"
VERSION="9.8 (Olive Jaguar)"
ID="almalinux"
ID_LIKE="rhel centos fedora"
VERSION_ID="9.8"
PLATFORM_ID="platform:el9"
PRETTY_NAME="AlmaLinux 9.8 (Olive Jaguar)"
ANSI_COLOR="0;34"
LOGO="fedora-logo-icon"
CPE_NAME="cpe:/o:almalinux:almalinux:9::baseos"
HOME_URL="https://almalinux.org/"
DOCUMENTATION_URL="https://wiki.almalinux.org/"
BUG_REPORT_URL="https://bugs.almalinux.org/"

ALMALINUX_MANTISBT_PROJECT="AlmaLinux-9"
ALMALINUX_MANTISBT_PROJECT_VERSION="9.8"
REDHAT_SUPPORT_PRODUCT="AlmaLinux"
REDHAT_SUPPORT_PRODUCT_VERSION="9.8"
SUPPORT_END=2032-06-01
uname -r
5.14.0-687.55.1.el9_8.x86_64
nft --version
-bash: nft: command not found

La distribution était AlmaLinux 9.8 et le noyau en cours d'exécution 5.14.0-687.55.1.el9_8. La commande nft qu'utilise la règle de blocage temporaire était absente elle aussi, ce qui signifie que le paquet nftables n'était pas installé.

rpm -q kernel
kernel-5.14.0-611.30.1.el9_7.x86_64
kernel-5.14.0-687.49.1.el9_8.x86_64
kernel-5.14.0-687.55.1.el9_8.x86_64

[rpm -q kernel] affiche la liste des noyaux installés, mais jusqu'au redémarrage, seul celui qu'indique [uname -r] fonctionne réellement. Comparez cette version avec la version corrigée de l'annonce d'AlmaLinux.

DistributionVersion du noyau corrigé (cette version ou plus récente)
AlmaLinux 8kernel-4.18.0-553.182.1.el8_10
AlmaLinux 9kernel-5.14.0-687.64.1.el9_8
AlmaLinux 10kernel-6.12.0-211.72.1.el10_2

5.14.0-687.55.1.el9_8 était inférieure à 5.14.0-687.64.1.el9_8, la version corrigée pour AlmaLinux 9 : il fallait donc mettre à jour.

Pour savoir si l'attaque disposait d'un chemin ouvert, nous avons vérifié les ports TCP IPv4 en écoute et l'état de MPTCP.

ss -lnt4
State  Recv-Q Send-Q Local Address:Port Peer Address:Port
LISTEN 0      128          0.0.0.0:22        0.0.0.0:*
LISTEN 0      511          0.0.0.0:443       0.0.0.0:*
LISTEN 0      511          0.0.0.0:80        0.0.0.0:*
sysctl net.mptcp.enabled
net.mptcp.enabled = 0
ss -lnM
State Recv-Q Send-Q Local Address:Port Peer Address:Port

Les ports TCP IPv4 en écoute sur toutes les adresses (0.0.0.0) étaient le 80 et le 443 du serveur web, ainsi que le 22 de SSH.

[net.mptcp.enabled] valait 0 et il n'y avait aucun socket MPTCP : la voie MPTCP utilisée par l'attaque publiée était donc fermée. La faille part toutefois des connexions TCP IPv4 ordinaires, si bien qu'un serveur qui écoute sur trois ports IPv4 a toujours besoin du correctif.

3️⃣ Mise à jour du noyau Linux : sept paquets du noyau et un redémarrage

Avant de changer de noyau, nous avons créé un instantané manuel de l'instance dans la console Lightsail. Lightsail n'a aucun écran pour choisir le noyau de démarrage : si le serveur ne redémarre pas avec le nouveau noyau, on le restaure en créant une nouvelle instance à partir de cet instantané.

🔲 Simulateur d'instantanés Lightsail

📍 Lightsail › 인스턴스 › AlmaLinux-9-1 › 스냅샷
AmazonLightsail문서 검색홈example (000000000000)▼
보안 업데이트를 권장합니다.

Linux 기반 블루프린트를 사용하는 인스턴스에 취약점(CVE-2026-98432)이 발생할 수 있습니다. 인스턴스가 영향을 받는지 확인하고 사용 중인 Linux 배포판에 최신 보안 업데이트를 적용하는 것이 좋습니다.

자세히 알아보기
AlmaLinux-9-1 정보
삭제재부팅중지
2 GB RAM, 2 vCPU, 60 GB SSD 플랜 변경
알마리눅스
AWS 리전
버지니아, 영역 A
(us-east-1a)
인스턴스 유형
범용
네트워킹 유형
듀얼 스택
네트워킹 유형 변경
고정 IP 주소
203.0.113.10
프라이빗 IPv4 주소
192.0.2.10
퍼블릭 IPv6 주소
2001:db8:1234:5678::a1b2
인스턴스 상태
실행 중
시스템 상태 확인
통과됨
인스턴스 상태 확인
통과됨
연결지표스냅샷스토리지네트워킹도메인고급도움말 및 지원
수동 스냅샷

스냅샷을 생성하여 인스턴스, 해당 시스템 디스크 및 연결된 디스크를 백업할 수 있습니다.

스냅샷을 생성 중…“”
2026년 11월 3일, 20:01 (UTC+0:00)“AlmaLinux-9-1-1762200000”
1 스냅샷 중 1 표시
자동 스냅샷
자동 스냅샷이 활성화됨

일일 스냅샷 시간은 오전 5:00 GMT+0입니다.Amazon은 가장 최근의 스냅샷 7개를 저장합니다.

🔲 Vérifier la mise à jour du noyau Linux et le redémarrage

Nous avons vérifié avec une liste dnf la version du noyau corrigé publiée dans le dépôt.

dnf --showduplicates list available kernel kernel-core kernel-modules kernel-modules-core kernel-tools kernel-tools-libs kernel-headers
kernel.x86_64                 5.14.0-687.64.1.el9_8   baseos
kernel-core.x86_64            5.14.0-687.64.1.el9_8   baseos
kernel-modules.x86_64         5.14.0-687.64.1.el9_8   baseos
kernel-modules-core.x86_64    5.14.0-687.64.1.el9_8   baseos
kernel-tools.x86_64           5.14.0-687.64.1.el9_8   baseos
kernel-tools-libs.x86_64      5.14.0-687.64.1.el9_8   baseos
kernel-headers.x86_64         5.14.0-687.64.1.el9_8   appstream
dnf download kernel-core-5.14.0-687.64.1.el9_8

Télécharge uniquement le fichier du paquet kernel-core dans le dossier courant, sans l'installer.

rpm -Kv kernel-core-5.14.0-687.64.1.el9_8.x86_64.rpm
    V4 RSA/SHA256 Signature, key ID b86b3716: OK
rpm -qp --changelog kernel-core-5.14.0-687.64.1.el9_8.x86_64.rpm | grep CVE-2026-98432
- ipv4: free inet_opt and ireq_opt after an RCU grace period (CKI Backport Bot) [RHEL-295635] {CVE-2026-98432}

La signature était OK et le journal des modifications contenait une ligne corrigeant CVE-2026-98432. Les avis de sécurité dnf (updateinfo) consultés le 3 novembre ne mentionnaient pas encore cette CVE : [dnf upgrade --security] ne permettait donc pas de récupérer ce noyau.

Nous avons donc installé les sept paquets du noyau en précisant aussi leur version.

dnf install -y kernel-5.14.0-687.64.1.el9_8 kernel-core-5.14.0-687.64.1.el9_8 kernel-modules-5.14.0-687.64.1.el9_8 kernel-modules-core-5.14.0-687.64.1.el9_8 kernel-tools-5.14.0-687.64.1.el9_8 kernel-tools-libs-5.14.0-687.64.1.el9_8 kernel-headers-5.14.0-687.64.1.el9_8
================================================================================
 Package                Architecture Version                    Repository    Size
================================================================================
Installing:
 kernel                 x86_64    5.14.0-687.64.1.el9_8      baseos       1.1 M
 kernel-core            x86_64    5.14.0-687.64.1.el9_8      baseos        17 M
 kernel-modules         x86_64    5.14.0-687.64.1.el9_8      baseos        40 M
 kernel-modules-core    x86_64    5.14.0-687.64.1.el9_8      baseos        31 M
Upgrading:
 kernel-headers         x86_64    5.14.0-687.64.1.el9_8      appstream    2.6 M
 kernel-tools           x86_64    5.14.0-687.64.1.el9_8      baseos       1.3 M
 kernel-tools-libs      x86_64    5.14.0-687.64.1.el9_8      baseos       1.1 M
Removing:
 kernel                 x86_64    5.14.0-611.30.1.el9_7      @baseos        0
 kernel-core            x86_64    5.14.0-611.30.1.el9_7      @baseos       64 M
 kernel-modules         x86_64    5.14.0-611.30.1.el9_7      @baseos       33 M
 kernel-modules-core    x86_64    5.14.0-611.30.1.el9_7      @baseos       27 M

Transaction Summary
================================================================================
Install  4 Packages
Upgrade  3 Packages
Remove  4 Packages

Total download size: 94 M

Complete!

Quatre nouveaux paquets du noyau ont été installés, les trois paquets kernel-headers, kernel-tools et kernel-tools-libs ont été mis à jour, et aucun autre paquet n'a changé. Comme le paramètre [installonly_limit=3] conserve jusqu'à trois noyaux installés, les quatre paquets du plus ancien, 5.14.0-611.30.1.el9_7, ont été supprimés ; du téléchargement à la fin, il a fallu 74 secondes.

La commande officielle indiquée dans l'annonce d'AlmaLinux récupère à nouveau les informations des dépôts, puis met à jour tous les paquets pour lesquels une mise à jour existe.

sudo dnf clean metadata && sudo dnf upgrade

Comme d'autres paquets que le noyau sont aussi mis à jour, les étapes pour mettre à niveau toute la version de la distribution sont détaillées dans Mise à jour d'Alma Linux : 9.4 → 9.8 sur LightSail.

Le nouveau noyau ne s'applique qu'après un redémarrage.

systemctl reboot

Une fois le serveur redémarré, nous avons vérifié tour à tour le noyau en cours d'exécution, les noyaux installés et le noyau par défaut.

uname -r
5.14.0-687.64.1.el9_8.x86_64
rpm -q kernel
kernel-5.14.0-687.49.1.el9_8.x86_64
kernel-5.14.0-687.55.1.el9_8.x86_64
kernel-5.14.0-687.64.1.el9_8.x86_64
grubby --default-kernel
/boot/vmlinuz-5.14.0-687.64.1.el9_8.x86_64

Le serveur est revenu moins d'une minute après la commande de redémarrage, et le noyau en cours d'exécution comme le noyau par défaut du prochain démarrage sont passés à 5.14.0-687.64.1.el9_8. L'ancien noyau 5.14.0-687.55.1.el9_8 est toujours installé : si le nouveau noyau pose problème, vous pouvez rétablir le noyau par défaut.

CatégorieAvant le correctifAprès le correctif
Noyau en cours d'exécution (uname -r)5.14.0-687.55.1.el9_85.14.0-687.64.1.el9_8
Noyau par défaut (grubby)5.14.0-687.55.1.el9_85.14.0-687.64.1.el9_8
Noyaux installés (rpm -q kernel)5.14.0-611.30.1.el9_7, 5.14.0-687.49.1.el9_8, 5.14.0-687.55.1.el9_85.14.0-687.49.1.el9_8, 5.14.0-687.55.1.el9_8, 5.14.0-687.64.1.el9_8

4️⃣ Blocage temporaire avant le redémarrage : règles nft et leurs limites

Si vous ne pouvez pas redémarrer tout de suite, vous pouvez bloquer avec une règle temporaire les paquets qui déclenchent la faille, en attendant d'installer le noyau corrigé. Nous n'avons pas exécuté nous-mêmes les commandes de cette section ; elles suivent les consignes officielles (les annonces d'AlmaLinux et d'AWS).

Sur le serveur Lightsail sous AlmaLinux 9.8 avec Nginx et Apache, un redémarrage ne prend que quelques minutes ; nous avons donc mis à jour le noyau directement, sans blocage temporaire.

La faille n'est déclenchée que par des demandes de connexion TCP qui portent des options IPv4. Le trafic normal n'utilise presque jamais d'options IPv4 : en bloquant uniquement les paquets TCP IPv4 avec options, les connexions habituelles continuent de fonctionner.

sudo dnf install -y nftables

La commande nft fait partie du paquet nftables, qui s'installe avec firewalld. Si la commande est absente de votre serveur, installez-le d'abord.

sudo nft -f - <<'EOF'
add table ip cve_2026_98432
delete table ip cve_2026_98432
table ip cve_2026_98432 {
    chain prerouting {
        type filter hook prerouting priority -300; policy accept;
        meta l4proto tcp ip hdrlength > 5 counter drop
    }
}
EOF

Crée une table qui bloque à l'étape prerouting les paquets TCP dont la longueur d'en-tête IPv4 dépasse 5, c'est-à-dire les paquets avec options IPv4. AlmaLinux a testé cette règle sur 8, 9 et 10 ; elle peut s'utiliser avec firewalld et s'exécuter plusieurs fois sans risque.

sudo nft list table ip cve_2026_98432

Vérifie que la règle est en place ; la valeur counter dans la sortie correspond au nombre de paquets bloqués jusqu'ici.

sudo nft delete table ip cve_2026_98432

Après le redémarrage sur le noyau corrigé, supprimez la table avec cette commande.

Cette règle disparaît au redémarrage ; si vous avez redémarré avant d'installer le noyau corrigé, exécutez de nouveau la commande qui crée la table.

Cette règle ne convient pas aux serveurs dont des applications dépendent des options IPv4. Les réseaux qui utilisent des étiquettes de sécurité CIPSO (NetLabel), transportées dans les options IPv4, en sont un exemple ; elles ne sont pas utilisées dans la configuration par défaut.

La règle protège l'hôte et les conteneurs qui reçoivent leur trafic via l'hôte (le mode par défaut de Podman et Docker). Le trafic échangé entre conteneurs d'un même hôte peut contourner cette règle.

Sous Debian, Ubuntu et openSUSE, utilisez la règle iptables d'une ligne fournie par le guide d'AWS. Les noyaux d'AlmaLinux 9 et de CentOS Stream 9 n'ont pas la correspondance u32 qu'utilise cette règle : utilisez plutôt la règle nft ci-dessus.

sudo iptables -I INPUT 1 -p tcp -m u32 --u32 '0>>24&0x0f=6:15' -j DROP

L'expression u32 lit le champ de longueur de l'en-tête IPv4 ; une valeur supérieure à 5 signifie que le paquet porte des options IPv4. Après avoir installé le noyau corrigé, supprimez cette règle avec la commande ci-dessous.

sudo iptables -D INPUT -p tcp -m u32 --u32 '0>>24&0x0f=6:15' -j DROP

Fermer dans le pare-feu Lightsail les ports inutilisés et limiter les autres à des adresses IP de confiance est une autre mesure recommandée par le guide d'AWS.

🔢 FAQ & contenus recommandés

Les annonces d'AlmaLinux et d'AWS indiquent toutes deux que les connexions IPv6 ne sont pas touchées par le problème principal de cette faille et qu'aucune règle temporaire n'est nécessaire pour elles. Mais même sur un serveur que vous pensiez uniquement en IPv6, si SSH ou le serveur web écoute sur au moins un port TCP IPv4, une attaque peut passer par ce port. Vérifiez donc avec [ss -lnt4] et appliquez quand même le correctif du noyau.

L'annonce d'AlmaLinux indique qu'un problème similaire existe lorsque la migration des sockets de requête TCP est activée (le paramètre net.ipv4.tcp_migrate_req ou un programme BPF qui déplace les requêtes). Ce paramètre est désactivé par défaut ; si vous l'avez activé, passez au noyau corrigé, puis consultez les mises à jour de l'annonce d'AlmaLinux.

Le guide d'AWS indique que Debian 11 et openSUSE Leap 15 ne sont plus pris en charge et risquent de ne plus recevoir de mises à jour du noyau. AWS recommande d'appliquer d'abord la règle de pare-feu temporaire sur ces serveurs, puis de prévoir le passage à une instance avec une version prise en charge.

ℹ️ Mention d'affiliation
Le contenu de ce site contient des liens d'affiliation. Lorsqu'un visiteur achète un produit ou un service via l'un de ces liens, le site perçoit une commission du vendeur. Le montant payé par l'acheteur(il baisse lors des promotions ↓), lui, n'augmente pas. Les prix, remises et stocks indiqués correspondent à la date de rédaction et peuvent différer ; vérifiez-les donc auprès du vendeur avant d'acheter. Les produits sont choisis et évalués selon nos propres critères, et les commissions n'influencent ni l'ordre de présentation ni le contenu des évaluations.

Laisser un commentaire

Votre adresse e-mail ne sera pas publiée. Les champs obligatoires sont indiqués avec *

Prouvez que vous êtes humain : 3   +   3   =