Boîte à outils d'atténuation CVE-2026-98432

Use-after-free IPv4 TCP inet_opt/ireq_opt (correctif amont e3f33b0a, kfree → kfree_rcu dans inet_sock_destruct() + tcp_v4_reqsk_destructor()). Déclencheur : SYN client transportant des options IPv4 (ihl > 5) — sans options, l'objet en course ireq_opt n'est jamais alloué. L'exploit revendiqué de root à distance nécessite en outre un listener MPTCP.

Fichiers

fichier	nécessite root	objectif
`cve-audit.sh`	non	rapport en lecture seule d'exposition + de correctibilité
`cve-mitigate.sh`	apply/undo	rejet nft des SYN avec options IP, désactivation MPTCP optionnelle
`nft-rules.txt`	—	le ruleset autonome (`nft -f nft-rules.txt`)
`cve-detect.sh`	modes capture	capteur tcpdump pour la forme des paquets de l'exploit
`kpatch-el-build.sh`	build/install	constructeur kpatch/livepatch validé pour la famille EL
`klp-handcraft-build.sh`	build/load	module klp écrit à la main pour les noyaux IBT où kpatch-build ne peut pas s'exécuter (EL10)
`patches/CVE-2026-98432.patch`	—	correctif amont, prêt pour kpatch-build
`tests/run-tests.sh`	non	harnais (chargement du ruleset en netns + e2e du constructeur simulé)

Démarrage rapide en incident

./cve-audit.sh                                # where do I stand?
./cve-mitigate.sh apply --with-mptcp-off      # closes trigger + claimed root path
./cve-detect.sh count 30                      # anyone probing with IP options?
sudo ./kpatch-el-build.sh --name CVE-2026-98432 \
     --expect inet_sock_destruct,tcp_v4_reqsk_destructor \
     [--sign priv.pem cert.pem] [--install] \
     patches/CVE-2026-98432.patch
# verify: cat /sys/kernel/livepatch/CVE-2026-98432/enabled  -> 1
./cve-mitigate.sh status                      # keep until 100% patched, then:
./cve-mitigate.sh undo

Matrice EL

cible	notes
EL7 (3.10)	non vulnérable (le code de déclenchement est arrivé en 4.4) ; le builder fonctionne toujours pour d'autres correctifs
EL7h/EL8 (4.18)	vulnérable ; kernel-debuginfo fournit `/usr/src/debug/kernel-/linux-` ; kpatch-build depuis EPEL
EL9 (5.14)	vulnérable ; noyau compilé avec gcc-toolset — le builder préfixe automatiquement avec le `/opt/rh/gcc-toolset-*` correspondant
EL10 (6.12)	IBT : kpatch-build 0.9.11 refuse les noyaux `CONFIG_X86_KERNEL_IBT=y` (dynup/kpatch#1320) — utilisez `klp-handcraft-build.sh` ; signature des modules imposée sous Secure Boot/lockdown
CloudLinux 8/9/10	l'identifiant de distribution n'est pas dans la liste de prise en charge de kpatch-build, donc le builder passe toujours `-s/-c/-v` explicitement ; les debuginfo proviennent du kernel-debuginfo AlmaLinux/CentOS correspondant à `rpm -qf /boot/vmlinuz-$(uname -r)`

Les debuginfo sur RHEL nécessitent l'activation de dépôts, par ex. dnf --enablerepo='*debug*' debuginfo-install -y $(rpm -qf /boot/vmlinuz-$(uname -r)) (subscription-manager repos --enable=rhel-9-appstream-rpms etc. sur les hôtes non facturés).

Ce que le builder valide avant que vous ne chargiez quoi que ce soit

CONFIG_LIVEPATCH=y + CONFIG_KALLSYMS=y dans la configuration en cours d'exécution.
Le noyau cible == le noyau en cours d'exécution (mur vermagic), kernel-devel/debuginfo/vmlinux présents.
Le correctif s'applique en avant ; s'il s'applique en inverse, on vous indique que le noyau contient déjà le correctif (kpatch échouerait plus tard avec « no functional changes »).
Le compilateur correspond au gcc de compilation du noyau (vérification au niveau .comment déléguée à kpatch-build ; la recherche du toolset est faite ici).
Après compilation : vermagic, et une liste blanche bidirectionnelle stricte des fonctions modifiées (--expect) — un troisième objet de modification inattendu est un échec dur.
sign-file optionnel avec votre paire de clés + revérification de modinfo sig_type ; enrôlez le certificat via MOK pour Secure Boot.
--install dépose dans /var/lib/kpatch/$(uname -r)/, charge via kpatch/insmod, active kpatch.service pour la persistance au redémarrage.

Procédure canary (à faire avant le déploiement sur la flotte)

VM canary, même uname -r que la flotte.
./kpatch-el-build.sh ... --install ; confirmez /sys/kernel/livepatch/<name>/enabled == 1.
Test de course : depuis une seconde machine, inondez avec hping3 -S -p <port> --tcp-opts ... un port en écoute tout en basculant net.ipv4.tcp_migrate_req=1 sur la canary ; une variante du noyau avec KASAN et un udelay() artificiel à l'intérieur de ip_options_build() devrait reproduire l'UAF sans le correctif et rester silencieuse avec.
Surveillez que uname -r reste inchangé (livepatch ne l'incrémente pas), kpatch list, dmesg -w pour la taint et les blocages de transition klp (/sys/kernel/livepatch/<name>/transition doit retomber à 0).
Déployez sur la flotte ; retirez la règle nft 24–48 h après une couverture à 100 %.
Redémarrez sur le noyau du fournisseur à la prochaine fenêtre quoi qu'il arrive — les livepatches s'empilent mal lors des changements de noyau.

Statut / honnêteté

Harnais : toutes les vérifications passent sur une VM AlmaLinux 10.2 (noyau 6.12.0-211.64.1.el10_2). De vrais jeux de règles nft sont chargés et listés dans un netns frais ; les filtres pcap sont compilés contre tcpdump en direct ; le pipeline du builder est exercé de bout en bout contre un kpatch-build simulé avec un vrai fichier .ko et des flux de symboles injectés.

Vérifié en direct sur cette VM EL10 :

klp-handcraft-build.sh --load a construit et activé un livepatch : /sys/kernel/livepatch/klp_CVE_2026_98432/enabled=1, transition drainée, sysfs liste inet_sock_destruct,1 + tcp_v4_reqsk_destructor,1 ; le TCP normal (HTTP 200) n'est pas affecté. Un .ko non signé souille le noyau ; le verrouillage Secure Boot le refuserait (la VM s'exécutait sans signature).
Le vrai kpatch-build (dynup 0.9.11, compilé depuis les sources) échoue durement sur EL10 avec « kernel option CONFIG_X86_KERNEL_IBT not supported » — le builder effectue désormais un précontrôle de ce point et renvoie vers la voie artisanale. Une véritable exécution de kpatch-build par diff binaire reste non testée sur EL8/EL9.
Atténuation en direct : 20 SYN à options scapy sur le réseau ont été comptés et supprimés par la règle de garde ; 3 SYN simples sont passés ; ssh n'est pas affecté.
Constat de terrain : sur EL10 6.12.0-211, les SYN forgés avec options IP atteignent le hook raw prerouting de nft (-300) mais n'atteignent jamais le hook INPUT (port ouvert, lo et netns propre reproduisent tous le cas ; aucun événement tracepoint kfree_skb, bien que SELinux ait bloqué perf/kprobes et que tcpdump n'ait rien capturé, donc la fonction exacte de suppression reste non résolue). La chaîne d'atténuation accroche donc prerouting priority raw, qui les observe et les supprime ; la règle d'un ami à prerouting priority -310 fonctionne pour la même raison. Exécutez le chemin nominal une fois sur votre canari EL avant de lui faire confiance lors d'un incident.

cve-2026-98432

Populaires