
kpatch livepatch pour CVE-2026-98432 (et CVE-2026-99999) sur AlmaLinux et Rocky Linux 8, 9 et 10
Modules livepatch qui corrigent CVE-2026-98432 sur un hôte AlmaLinux ou Rocky Linux 8, 9 ou 10 (x86_64) en cours d'exécution, sans redémarrage. Sur les noyaux auxquels manque également le correctif de CVE-2026-99999, le même module corrige aussi ce dernier, de sorte qu'un hôte n'a besoin que d'un seul module, quel que soit celui des deux qui manque à son noyau.
Statut (2026-11-02) : chaque module est compilé et testé en chargement ; aucun
n'est encore publié, il n'y a donc rien à appliquer. La publication, ainsi qu'un
test de la commande en une ligne sur chaque module publié, viennent ensuite ;
d'ici là, scripts/livepatch.sh n'a aucun module dans sa table et refuse tous les
noyaux.
684 noyaux : 380 d'AlmaLinux et 304 de Rocky Linux, de 8.3 à 10.2,
listés dans tools/kernels.tsv. Il s'agit de tous les noyaux dont le SRPM et
les debuginfo sont sur les miroirs de la distribution (vault inclus), x86_64
uniquement, à l'exception de 5.14.0-611.41.1.el9_7 de Rocky, dont les debuginfo ne
sont sur aucun miroir. Cela inclut l'unique noyau 8.3 de Rocky, 4.18.0-240.22.1.el8, que
le précédent dépôt Rocky ne couvrait pas, ainsi que les noyaux que les deux
distributions ont publiés après les précédents dépôts, jusqu'à
4.18.0-553.180.1.el8_10 (AlmaLinux), 5.14.0-687.61.1.el9_8 et
6.12.0-211.69.1.el10_2. La variante x86_64_v2 d'AlmaLinux 10 n'est pas couverte.
666 des 684 manquent aussi du correctif de CVE-2026-99999, et leur module porte les deux. Les 18 autres l'ont déjà (à partir d'AlmaLinux 4.18.0-553.177.1.el8_10 et de Rocky 553.178.1.el8_10, et à partir de 5.14.0-687.59.1.el9_8 et 6.12.0-211.67.1.el10_2 sur les deux), et leur module ne porte que la modification de CVE-2026-98432.
Chaque module a été compilé en CI et appliqué avec scripts/livepatch.sh à
son noyau livré dans une VM (tools/loadtest.sh), le 2026-10-31, une exécution
par distribution et version mineure, 40 exécutions ; les 684 ont affiché RESULT: PASS.
Dans chacune :
inet_sock_destruct et tcp_v4_reqsk_destructor sont listées comme
fonctions corrigées de vmlinux.tools/tcpopt.py). Cela sollicite les deux libérations
que le correctif modifie avec les options présentes ; sans options IP, elles ne libèrent
que NULL.nfnetlink_queue et xt_CHECKSUM (et sur 9 et 10
nf_conntrack_bridge). Sur 8 et 9 (511 noyaux, et le 8.3 de Rocky), une
trame forgée a été fragmentée par le noyau livré et rejetée avec le
module appliqué. Sur 10 (154 noyaux), la trame est refusée avant d'atteindre
la faille, si bien que cette sonde ne dit rien dans un sens comme dans l'autre.Non testé : la course elle-même. Démontrer CVE-2026-98432 sur le noyau livré
et son absence avec le module nécessite KASAN et un entrelacement artificiel
d'un SYN retransmis avec la libération de l'enfant ; cela ne se produit pas
à la demande dans ces VM. Aucun module n'a non plus été testé avec Secure
Boot activé (il n'est pas signé et serait refusé), ni chargé au démarrage par
kpatch.service.
tools/mkdiffs.sh porte chaque SRPM de noyau d'une version mineure. Il applique
d'abord les correctifs propres du SRPM à son tarball, comme le fait %prep
(tools/prep.py) : AlmaLinux y intègre ses propres correctifs, parmi lesquels
celui de CVE-2026-99999 dans 4.18.0-553.177.1.el8_10, et le 6.12.0-211.69.1 de 10.2
est le tarball 211.56.1 de Red Hat plus 466 correctifs, si bien qu'un port réalisé
à partir du tarball nu manquerait ce que contient le noyau. Les lignes modifiées
sont ensuite vérifiées par rapport à tools/ref/ : celles de CVE-2026-98432 doivent être égales
à celles d'amont, celles de CVE-2026-99999 au correctif d'AlmaLinux pour 8 ou 9 ou à celui d'amont
pour 10, ou être absentes là où le noyau possède ce correctif. Les 684
correspondent. tools/port.py s'arrête aussi si le kfree_rcu() de l'arbre ne
sauterait pas un pointeur NULL, comme le sont habituellement les deux pointeurs.
8 et 9 sont construits avec kpatch-build, 10 avec le klp-build du noyau lui-même ; les deux construisent des patchs de remplacement, ce qui permet à un module de prendre le relais d'un précédent.
Le correctif amont est torvalds/linux e3f33b0a1d89, « ipv4: free inet_opt and
ireq_opt after an RCU grace period ». Lorsqu'un SYN transporte des options IP, le
listener les conserve sur la socket de requête (ireq_opt) et les transmet à
la socket enfant (inet_opt) sans les copier. Un SYN retransmis pour la
même requête peut recevoir un SYN-ACK sur un autre CPU, lisant ces
options sous RCU, tandis que l'enfant est fermé et que inet_sock_destruct()
les libère avec un simple kfree() : un use after free. La migration de la
socket de requête présente le même problème dans tcp_v4_reqsk_destructor(). Le correctif
libère les deux avec kfree_rcu().
Aucune des deux distributions n'a publié le correctif : le 2026-10-27, les plus récents
noyaux d'AlmaLinux et de Rocky Linux 8, 9 et 10 ne mentionnaient pas la CVE dans
leurs changelogs, et les sources de 4.18.0-305.3.1.el8_4,
4.18.0-553.179.1.el8_10, 5.14.0-687.61.1.el9_8 et 6.12.0-211.68.1.el10_2
libèrent toujours les deux pointeurs avec kfree().
Corrigée plus tôt, séparément pour chaque distribution, par nsrg-fmlorg/kpatch-alma-cve-2026-99999 et nsrg-fmlorg/kpatch-rocky-cve-2026-99999. Les deux distributions livrent désormais des noyaux intégrant ce correctif, à partir de 4.18.0-553.177.1.el8_10 (AlmaLinux) ou 553.178.1.el8_10 (Rocky), 5.14.0-687.59.1.el9_8 et 6.12.0-211.67.1.el10_2. Lorsqu'un noyau en est dépourvu, le module de ce dépôt porte la même modification que les précédents, et remplace un module déjà chargé (testé sur chacun des 665 noyaux qui en avaient un, ci-dessus).