La vulnérabilité CVE-2026-98276 a été corrigée en amont. Puis, un serveur a planté à 12 reprises.

Principaux enseignements

• La vulnérabilité CVE-2026-98276 permet à un utilisateur local sans privilèges de provoquer une situation de « race condition » entre deux appels de socket afin de provoquer le plantage du noyau ou d'obtenir les droits root.
• Une faille qui avait provoqué 12 pannes de serveur permet désormais d'obtenir les privilèges root sur les versions EL 8, 9 et 10.
• Red Hat ne propose pas de noyau corrigé pour RHEL 7, 8, 9 ou 10 et n'indique aucune mesure corrective.
• Les correctifs KernelCare sans redémarrage sont désormais disponibles pour RHEL, AlmaLinux et CloudLinux 8 et 9, ainsi que pour Debian 12 et 13.

En bref

Aller directement à la version longue ↓

Ce qui s'est passé : Le 6 octobre 2026, l'équipe CVE du noyau CVE-2026-98276 publié, une utilisation après libération de mémoire dans les sockets UDP, causée par une situation de concurrence entre bind() et sock_gettstamp(), le gestionnaire qui signale à un programme l'arrivée du dernier paquet d'une socket. Tout utilisateur local capable d'ouvrir une socket UDP peut le déclencher, mais il n'est pas accessible depuis le réseau. Le 4 novembre, un exploit fonctionnel a été utilisé contre un serveur CloudLinux 8 et il l'a cassée 12 fois. Aller à cette section → (À quoi ressemblait l'attaque sur un serveur réel) . Depuis, TuxCare a mis au point un exploit permettant d'obtenir les droits root à partir du code récupéré sur ce serveur.

Qui est concerné : tout noyau n’ayant pas encore intégré le correctif, ce qui représente encore un grand nombre de systèmes de production. Cela inclut RHEL 7, 8, 9 et 10, ainsi que les versions dérivées utilisant le noyau Red Hat, notamment CloudLinux 8, 9 et 10. L’hébergement mutualisé constitue le point sensible, car les comptes clients peuvent souvent y exécuter leur propre code sur un noyau partagé par tous. Aller à cette section →

État des lieux :il ne s'agit pas d'une vulnérabilité « zero-day ». Le correctif était déjà disponible en amont et dans les branches stables avant même que quiconque ne signale une attaque, et aucun code d'exploitation n'a été rendu public. TuxCare a désormais confirmé une élévation de privilèges sur EL 8, 9 et 10, y compris sur le dernier noyau d'AlmaLinux 8 ; il faut donc considérer qu'il s'agit d'un accès root local dans ces environnements. Sur EL 7, l’évaluation de TuxCare fait état uniquement d’un plantage. Debian a corrigé ses noyaux, Ubuntu, Oracle et Amazon en ont corrigé certains, tandis que Red Hat n’a pas encore publié de correctif pour aucune version d’EL ni donné de date. Les correctifs sans redémarrage de KernelCare sont en production pour RHEL, AlmaLinux et CloudLinux 8 et 9, et EL 10 est en phase de test. Aller à cette section →

Que faire aujourd’hui : il n’y a pas de paramètre sysctl à modifier ni de règle de pare-feu utile ; la seule solution viable consiste donc à appliquer le correctif. Sur RHEL, AlmaLinux et CloudLinux 8 et 9, ainsi que sur Debian 12 et 13, les utilisateurs de KernelCare peuvent télécharger le correctif dès maintenant :

kcarectl --update

Vérifiez ensuite avec kcarectl --patch-info | grep 'CVE-2026-98276'. Sur EL 10, y compris CloudLinux 10, le correctif se trouve pour l'instant dans le canal de test ; ajoutez donc –prefix test à la commande de mise à jour. En attendant que le correctif soit disponible, limitez ou suspendez les comptes locaux auxquels vous ne faites pas confiance. Aller à cette section →

Les failles locales de type « déni de service » se retrouvent généralement reléguées au bas de la liste des priorités. L'attaquant doit d'abord s'introduire sur la machine, le résultat habituel se résume à un plantage et à un redémarrage, et la plupart des parcs informatiques ont des problèmes bien plus urgents à régler. Au départ, la faille CVE-2026-98276 semblait faire partie de cette catégorie, mais elle n'y est pas restée.

Quelqu'un l'a déjà utilisé. Le 4 novembre, un serveur CloudLinux 8 a subi 12 pannes à partir d'un exploit fonctionnel pour ce bug, et avec kernel.panic_on_oops = 1 Une fois configuré, chaque plantage entraînait un redémarrage complet. Deux jours plus tard, TuxCare disposait des droits root sur AlmaLinux 8 grâce à un exploit créé à partir du code récupéré sur ce serveur, et l’élévation de privilèges fonctionne désormais sur les versions EL 8, 9 et 10. Et il n’y a rien à désactiver. Le code vulnérable se trouve derrière une fonction ioctl de horodatage que n’importe quel processus peut appeler sur n’importe quelle socket UDP qu’il ouvre.

Les noyaux des éditeurs sont eux aussi à la traîne. Le correctif avait été intégré en amont avant la publication du CVE le 6 octobre ; Debian a mis à disposition des noyaux corrigés il y a plusieurs semaines, tandis que Red Hat continue d'indiquer que les versions RHEL 7 à 10 sont concernées, sans proposer de noyau corrigé ni donner de date.

Comment une requête avec horodatage libère un socket actif

SIOCGSTAMP et SIOCGSTAMPNS, ainsi que le _NEW Les versions utilisées par les noyaux récents pour la gestion du temps en 64 bits sont d’anciennes fonctions ioctl peu élégantes. Un programme en appelle une sur une socket pour savoir quand le dernier paquet est arrivé, et le noyau répond via sock_gettstamp() dans net/core/sock.c. La première fois qu'une requête est adressée à un socket, le gestionnaire active également l'horodatage en définissant la variable SOCK_TIMESTAMP un peu de sk->sk_flags.

Le problème, c'est qu'il le fait sans maintenir la douille en place, et que l'assistant qui se trouve en dessous utilise __set_bit(), qui n'est pas une opération atomique. Le processeur lit l'intégralité du mot de drapeaux, effectue une opération OU sur un bit, puis réécrit le mot entier. Si un autre élément modifie un autre bit de ce mot entre la lecture et l'écriture, cette modification est perdue.

Cet autre écrivain, c'est bind(). Lors de la liaison d'un socket UDP, udp_lib_get_port() ensembles SOCK_RCU_FREE et ajoute le socket à la table de hachage, où le chemin de réception UDP peut le trouver sans avoir à acquérir un verrou. SOCK_RCU_FREE C'est la garantie offerte par le noyau à ces lecteurs qui n'utilisent pas de verrou. Lorsque la socket se ferme, le noyau attend l'expiration d'un délai de grâce RCU avant de la libérer, afin que toute personne qui la consulte encore puisse terminer son opération.

Si vous exécutez les deux sur des processeurs différents, leur synchronisation risque d'être mauvaise. La fonction ioctl lit les indicateurs juste avant bind() ensembles SOCK_RCU_FREE, puis réécrit sa copie obsolète une fois que le socket figure déjà dans la table. L'indicateur a disparu, mais le socket reste visible pour les lecteurs sans verrouillage, et rien dans le noyau ne permet de savoir que la promesse n'a pas été respectée. Si on le ferme alors qu'un paquet est en cours de réception, le noyau libère immédiatement la mémoire alors que le chemin de réception l'utilise encore. C'est ce qu'on appelle une « utilisation après libération ».

Le corriger d'Eric Dumazet, qui s'empare du verrou de la douille sock_gettstamp(), mais uniquement lorsque SOCK_TIMESTAMP doit effectivement être configuré, afin que le chemin commun reste non verrouillé. Le Fiche CVE Le rapport est signé par Jungwoo Lee et Wongi Lee, et les données KASAN qu'il cite proviennent d'un programme de test mentionné par les journalistes. exploit.

Ce même message de commit souligne que sk_set_memalloc() et sk_clear_memalloc() modifier également sk_flags sans le verrou. Leurs appelants (nbd, iSCSI, NVMe over TCP, sunrpc et WireGuard) doivent d'abord faire l'objet d'un audit ; l'équipe en amont prévoit donc un correctif distinct. Il s'agit d'une correction distincte qui sera traitée ultérieurement et qui ne fait pas partie de ce CVE.

Tout noyau ne disposant pas de ce correctif reste vulnérable, et de nombreux noyaux d'entreprise en production ne l'ont pas encore intégré.

Le serveur attaqué fonctionnait avec un noyau CloudLinux 8, et chaque plantage laissait la même trace dans le journal du noyau. On observait d'abord des avertissements aux lignes 153 et 156 du fichier net/ipv4/af_inet.c, à l'intérieur inet_sock_destruct(), le code qui ferme une socket. Puis il y a eu une déréférence d'un pointeur NULL, soit dans udp_destruct_common() lorsque la prise s'est refermée ou dans __sk_mem_raise_allocated() appelé depuis __udp_enqueue_schedule_skb() alors qu’un paquet était en attente dans la file d’attente. Ces deux phénomènes sont tout à fait normaux lorsque le chemin de fermeture et le chemin de réception se disputent un socket qui n’existe plus.

Le serveur avait kernel.panic_on_oops = 1, une fonctionnalité utilisée par de nombreuses configurations d'hébergement pour que, lorsqu'un noyau présente un dysfonctionnement, le système redémarre plutôt que de continuer à fonctionner de manière instable. Cela a transformé chaque « oops » en redémarrage – douze au total. Le compte root n'a jamais été exposé sur ce serveur, seuls les plantages ont été observés, et aucun code d'exploitation n'a été rendu public.

Si un serveur redémarre sans raison apparente, vérifiez si ces noms de fonctions apparaissent dans le journal du noyau du démarrage précédent. Pour cela, il faut disposer d'un journal persistant :

journalctl -k -b -1 | grep -E 'inet_sock_destruct|udp_destruct_common|__sk_mem_raise_allocated|__udp_enqueue_schedule_skb'

Une correspondance ne constitue pas en soi la preuve d'une attaque, mais sur un noyau non mis à jour, c'est une bonne raison de vérifier qui était connecté et quelles applications étaient en cours d'exécution.

Du bug provoquant un plantage au bug de root

L'équipe CVE du noyau attribue à la vulnérabilité CVE-2026-98276 une note de 7,8 (« Élevé »), avec un vecteur d'attaque local, une complexité d'attaque faible, des privilèges faibles et un impact élevé sur la confidentialité, l'intégrité et la disponibilité. Red Hat lui attribue la note « modérée » (7,0), tout comme SUSE et Amazon. La différence réside entièrement dans la complexité de l’attaque, que ces fournisseurs jugent élevée car l’attaquant doit remporter une course contre la montre. C’est un argument valable en théorie, mais l’incident survenu avec CloudLinux 8 montre que cette course peut être remportée à maintes reprises sur un serveur de production.

L'écart le plus important se situait entre le score et les preuves, et cet écart s'est désormais comblé. Le vecteur 7.8 part du principe qu'une vulnérabilité de type « use-after-free » au niveau d'un socket, comme celle-ci, peut être exploitée pour obtenir une élévation de privilèges, et TuxCare y est désormais parvenu. Son équipe a obtenu les droits root sur AlmaLinux 8 avec le noyau par défaut, à l'aide d'un exploit créé à partir du code récupéré sur le serveur attaqué, et a depuis confirmé l'élévation de privilèges sur les versions EL 8, 9 et 10. Cela inclut le dernier noyau d’AlmaLinux 8, le 4.18.0-553.184.1.el8_10. L’exploit n’est pas parfaitement fiable, mais il a fonctionné à plusieurs reprises. Sur EL 7, l’évaluation de TuxCare fait état uniquement d’un plantage local. Pour toutes les autres versions de la famille EL, considérez qu’il s’agit d’un accès root local et accordez-lui une priorité plus élevée que ne le suggère son score de 7,0 attribué par le fournisseur.

CloudLinux 9 et 10 utilisent des noyaux AlmaLinux ; ils suivent donc la ligne AlmaLinux. Sous Ubuntu, la situation dépend de la version du noyau ; vérifiez donc le paquet que vous utilisez réellement plutôt que le numéro de version. Si vous compilez vos propres noyaux, n'importe laquelle des versions stables mentionnées ci-dessus contient le correctif.

Les anciennes versions couvertes par le programme « Endless Lifecycle Support » (ELS) de TuxCare sont en meilleur état que vous ne le pensez. Les noyaux ELS intégrant ce correctif ont été mis à disposition entre le 14 et le 26 octobre pour CentOS 6, Oracle Linux 6, CentOS 8.5 et Ubuntu 20.04, ainsi que les noyaux bénéficiant d'un support étendu pour AlmaLinux 9.2 et 9.6.

La plupart des bogues du noyau s'accompagnent d'un réglage à modifier en attendant que le correctif soit disponible, d'un module à décharger ou d'un paramètre sysctl à modifier. Celui-ci ne présente rien de tout cela. sock_gettstamp() Il s'agit d'un code de socket au cœur du système, et aucune option sysctl ni option de démarrage ne permet de le désactiver. Tout utilisateur lambda capable de créer une socket UDP peut y accéder, ce qui, sur une installation par défaut, concerne tout le monde.

Un pare-feu ne servira à rien. Le déclencheur réside dans quelques appels système effectués sur un socket contrôlé par l'attaquant, et aucun de ces appels ne passe par iptables ou nftables.

Une politique SELinux pourrait bloquer les ioctls d'horodatage. Sur CloudLinux, cependant, cPanel & WHM exigent que SELinux soit désactivé, ce qui exclut cette option pour de nombreux serveurs d'hébergement.

Il ne reste plus qu’à limiter les utilisateurs autorisés à exécuter du code sur le serveur hôte. Dans le cadre d’un hébergement mutualisé, cela concerne l’accès au shell, les tâches cron et toute application client capable d’exécuter ses propres binaires. Limitez ou suspendez les comptes auxquels vous ne faites pas confiance jusqu’à ce que le correctif soit appliqué, et surveillez les redémarrages inexpliqués, en gardant à l’esprit qu’ils ne reflètent peut-être que les tentatives infructueuses. Appliquez ensuite le correctif.

Le correctif sans redémarrage de KernelCare reprend tel quel le correctif en amont, en utilisant le verrou de socket lors de la mise à jour du drapeau. Il s'agit d'une modification mineure qui n'implique aucun changement de structure de données, ce qui en fait un correctif idéal pour une application sans redémarrage ; il est déployé sur l'ensemble de la gamme EL, alors que Red Hat ne propose toujours pas de noyau corrigé pour aucune version EL. LibCare n'est pas concerné, puisqu'il s'agit d'un bogue du noyau.

EL 7 fait exception. Selon l’évaluation de TuxCare, il s’agit d’un plantage local sans élévation de privilèges ; il n’est donc pas prévu d’appliquer le correctif avant Red Hat. Partout où un correctif est en production, les hôtes bénéficiant des mises à jour automatiques de KernelCare le récupèrent selon leur calendrier habituel ; vous pouvez également le récupérer immédiatement à l’aide de la commande `kcarectl –update`. Sur EL 10, y compris CloudLinux 10, le correctif se trouve pour l’instant dans le flux de test ; utilisez donc la commande `kcarectl –update –prefix test`. Aucun redémarrage n’est nécessaire dans les deux cas. Assurez-vous ensuite que le correctif a bien été appliqué :

kcarectl --patch-info | grep 'CVE-2026-98276'

Si rien ne s'affiche, cela signifie que KernelCare n'a pas encore appliqué de correctif pour ce CVE ; vérifiez donc si l'hôte utilise déjà un noyau corrigé par le fournisseur avant de conclure qu'il est vulnérable. Le CVE Tracker de TuxCare affiche l'état des correctifs sans redémarrage pour chaque distribution, au fur et à mesure des mises à jour.

Procurez-vous KernelCare dès aujourd’hui →

Quelques lignes de verrouillage et une longue attente

La correction en amont ne comporte que quelques lignes, et les utilisateurs de RHEL ne disposent toujours pas d'un noyau fourni par l'éditeur à installer.

Si l'on s'en tient aux critères habituels, personne n'aurait dû remarquer celle-ci. Le correctif a été déployé avant la publication du CVE, le CVE a été publié un mois avant que quiconque ne soit attaqué, et aucun code d'exploitation n'a été rendu public. En théorie, un bug provoquant un plantage local avec un score de 7,0 attribué par le fournisseur ne devrait pas être traité en priorité.

Puis, un exploit fonctionnel est apparu sur un serveur d’hébergement en production, alors que les noyaux de la famille RHEL, sur lesquels tournent de nombreux serveurs d’hébergement, ne disposent toujours pas de correctif du fournisseur. En l’espace de deux jours, ce même code d’exploit avait été transformé en exploit root. L’hébergement mutualisé est pratiquement le pire scénario possible en cas de faille locale. De nombreux clients peuvent exécuter leur propre code sous un compte local, et il suffit d’un seul d’entre eux pour mettre l’hébergeur hors service ou en prendre le contrôle, au détriment de tous les autres utilisateurs présents sur le serveur.

Si vous exploitez des serveurs multi-locataires, ne classez pas cette vulnérabilité dans la catégorie des attaques DoS locales. Sur les versions EL 8 à 10, il s'agit d'une vulnérabilité locale permettant l'accès root. Vérifiez les journaux à la recherche de la signature du plantage, renforcez la sécurité des comptes auxquels vous ne faites pas confiance et appliquez le correctif, soit via un correctif sans redémarrage lorsqu'il est disponible, soit en redémarrant avec un noyau corrigé si votre distribution en propose un.

Procurez-vous KernelCare dès aujourd’hui →

Comment cela s'est-il passé ?

Sources

Les sources principales de cet article sont l'annonce relative au CVE du noyau, la fiche CVE et le correctif en amont, ainsi que les pages des éditeurs Red Hat (y compris son système de suivi des bogues), Debian, Ubuntu, SUSE, Amazon et Oracle. Sont également cités le rapport d'incident de CloudLinux, l'entrée du NVD, la fiche de l'OSV, ainsi que les fiches de publication de KernelCare et ELS de TuxCare, à la date du 9 novembre 2026.