GhostLock transforme une faille de Futex vieille de 15 ans en un shell root

En bref

Aller directement à la version longue ↓

De quoi s'agit-il ? : GhostLock (CVE-2026-43499) est une vulnérabilité de type « use-after-free » présente dans le code d’héritage des priorités futex du noyau Linux, la fonctionnalité de verrouillage sur laquelle repose la bibliothèque glibc’s PTHREAD_PRIO_INHERIT mutex. Une étape de nettoyage efface les informations de gestion du thread erroné, laissant ainsi un thread actif pointer vers de la mémoire déjà libérée. Fait inhabituel, cette mémoire se trouve dans le noyau pile, et non dans le tas où se trouvent la plupart de ces bogues. Aller à la version longue →

Impact : élévation locale des privilèges jusqu’au niveau root. L’exploit public « full-chain » de Nebula Security permet d’atteindre le niveau root à partir d’un processus sans privilèges en environ cinq secondes, avec une fiabilité d’environ 97 %. Nous avons reproduit le déclenchement et le déni de service (DoS) local sur Debian 11/12/13, EL7 et EL10 ; il faut partir du principe que tout noyau affecté est exploitable jusqu’au niveau root, et pas seulement vulnérable au DoS. Accéder à la version longue →

Niveau de gravité : CVSS 7,8 (Élevé). Vecteur local, complexité faible, aucune interaction de l'utilisateur et chaîne LPE publique hautement fiable sur les cibles prises en charge. Red Hat attribue à cette vulnérabilité le niveau « Important ». Accéder à la version complète →

Qui est concerné : La seule condition préalable est CONFIG_FUTEX_PI=y, activée par défaut dans toutes les principales distributions ; aucune fonctionnalité particulière, aucun espace de noms ni aucun matériel spécifique n'est requis. Introduite dans Linux 2.6.39-rc1 (mai 2011), la plage de versions vulnérables s'étend jusqu'à la version v7.1-rc1 ; ainsi, la quasi-totalité des noyaux en production sont concernés. Aller à la version longue →

Faille associée : Une modification ultérieure, 74e144274af3 (CVE-2026-53166) a ensuite été annulé en amont en raison d'une régression. Vérifiez la couverture de GhostLock via CVE-2026-43499 et le correctif principal 3bfdc63936dd. Aller à la version longue →

Statut : Un « N-day », pas un « zero-day ». Signalé le 18 avril, corrigé en amont le 20 avril (3bfdc63936dd), puis rétroporté le 4 mai, le tout avant la divulgation publique du 7 juillet. Un exploit fonctionnel est accessible au public et la faille a déjà fait l'objet d'articles dans la presse spécialisée en sécurité. Aller à la version longue →

À faire immédiatement : il n’existe aucune mesure de protection à l’échelle du système ; la fonctionnalité vulnérable est intégrée au code source et ne peut pas être désactivée sur un noyau en cours d’exécution. Appliquez un noyau corrigé par le fournisseur ou un correctif KernelCare ne nécessitant pas de redémarrage. Dans les conteneurs, un filtre seccomp bloquant les opérations futex PI permet de corriger la vulnérabilité, au prix toutefois d’une interruption des charges de travail utilisant ces verrous. Accéder à la version longue →

Deux éléments pourraient vous inciter à classer ce ticket comme « faible priorité », mais ces deux raisons sont erronées.

Le premier est l’ancienneté du code. GhostLock réside dans une routine de verrouillage livrée en mai 2011. Un bug resté inaperçu pendant quinze ans ressemble à une curiosité théorique, le genre de découverte qui vaut une présentation lors d’une conférence mais qui n’affecte jamais un serveur de production. Ce point de vue est rassurant, mais erroné. Le bug est accessible depuis un processus sans privilèges sur un noyau par défaut, et il existe un exploit public complet qui permet d’obtenir un shell root en quelques secondes.

Le deuxième terme est « futex ». Un futex (mutex rapide de l’espace utilisateur) est un élément constitutif du noyau que des bibliothèques telles que glibc utilisent pour mettre en œuvre des verrous entre les threads. Cela ressemble à une complexité technique profonde que la plupart des applications ne touchent jamais directement, et c’est vrai, mais la fonctionnalité au cœur de ce bogue, le verrouillage par héritage de priorité, n’est pas une fonctionnalité de niche. CONFIG_FUTEX_PI est activé par défaut sur toutes les principales distributions ; glibc l'utilise pour PTHREAD_PRIO_INHERIT les mutex, et la voie d'exploitation est accessible sans capacités, espaces de noms ni matériel spécifique. Si votre noyau se trouve dans la plage concernée et a été compilé avec la configuration par défaut, cette vulnérabilité est présente.

GhostLock est la deuxième découverte de la série de recherches « IonStack » de Nebula Security, rendue publique le 7 juillet 2026 par l’équipe qu’elle désigne sous le nom de VEGA, accompagnée d’un rapport complet, d’une entrée dans la liste des failles et d’une preuve de concept publique couvrant l’ensemble de la chaîne. Elle a remporté une récompense de 92 337 dollars dans le cadre du kernelCTF de Google le 30 juin. Nous en avons pris connaissance le matin du 8 juillet, et un ingénieur de KernelCare a commencé à reproduire le problème sur différentes distributions le jour même.

Avant d'entrer dans les détails, il convient de garder à l'esprit un point essentiel : il s'agit d'un bogue de la branche principale, et non d'une particularité liée à une distribution. Tout noyau, de la version 2.6.39-rc1 à la version 7.1-rc1, compilé avec le PI futex contient le code vulnérable. L'exploit publié est spécifique à certaines cibles dans ses dernières étapes, mais la faille sous-jacente est pratiquement universelle.

Comment fonctionne GhostLock ?

Commençons par la partie du noyau concernée. Lorsqu’un thread attend un verrou à héritage de priorité, le noyau suit cette relation dans un petit enregistrement appelé « waiter » et indique, pour le thread en attente, sur quel verrou il est bloqué (un champ nommé pi_blocked_on). Il est important de bien mettre de l'ordre dans cette comptabilité, car si un thread se termine alors qu'il est toujours marqué comme bloqué sur un verrou qui n'existe plus, le noyau se retrouve avec un pointeur qui ne pointe vers rien.

La routine de nettoyage, remove_waiter(), a été écrit pour le cas le plus simple : un thread qui gère lui-même la fin de son attente. Il part du principe que le thread qui effectue cette gestion, que le noyau appelle current, est le même thread qui était en attente. Une opération plus avancée, appelée « requeue-PI », remet en cause cette hypothèse. La fonction « requeue-PI » déplace un thread en attente d’un verrou vers un autre (c’est ainsi que les variables de condition sont implémentées efficacement), ce qui signifie que c’est le thread exécutant le nettoyage qui effectue le déplacement, et non celui qui était en attente.

Voici où se situe l'erreur. Lorsque le noyau détecte qu'une remise en file d'attente entraînerait un blocage (un cycle dans lequel chaque thread attend le suivant) et qu'il interrompt l'opération en renvoyant une erreur, la procédure de restauration appelle remove_waiter(), et remove_waiter() efface current->pi_blocked_on, le de déménagement enregistrement, au lieu de celui du véritable serveur. Le thread d'attente n'est jamais libéré. Lorsqu'il revient dans l'espace utilisateur, son pi_blocked_on pointe toujours vers son propre cadre de pile, que le noyau a depuis réutilisé à d'autres fins. Ce pointeur orphelin pointant vers de la mémoire de pile libérée correspond à une utilisation après libération.

D'une manière générale, l'exploit s'appuie sur ce principe comme suit :

[Unprivileged process, three threads/futexes]
│  stage a deadlock cycle so the kernel takes the buggy rollback path
▼
[remove_waiter() clears the wrong thread's record → a live thread points into its own freed stack frame]
│
▼
[Reclaim that freed frame with attacker-controlled data → forge a fake waiter record]
│
▼
[Trigger the cleanup again → write one attacker-chosen pointer into a kernel network table]
│
▼
[Point that table entry at attacker code → send one IPv6 UDP packet to run it]
▼
[Flip a system setting (core_pattern) so a crash handler runs as root → root shell]

Pour ceux qui le souhaitent, voici une explication détaillée du mécanisme : l'attaquant provoque le blocage à trois fils à l'aide de futexes en utilisant le FUTEX_LOCK_PI, FUTEX_WAIT_REQUEUE_PI, et FUTEX_CMP_REQUEUE_PI opérations, ce qui oblige le -EDEADLK (blocage) et la restauration défectueuse. Ils récupèrent ensuite la trame de pile libérée à l'aide de PR_SET_MM_MAP, un appel de contrôle de processus qui permet à un programme de définir des champs que le noyau copie dans sa propre pile, remplissant ainsi cette mémoire avec des données falsifiées rt_mutex_waiter enregistrement. Le nettoyage de l'arborescence des éléments en attente du noyau se résume alors à une seule écriture contrôlée dans un pointeur, visant à inet6_protos[IPPROTO_UDP], l'entrée de table qui indique au noyau quelle fonction gère les paquets UDP IPv6 entrants. L’attaquant redirige cette entrée vers une instruction « pivot » placée à une adresse fixe et prévisible (la zone d’entrée du processeur, une région propre à chaque processeur qui se trouve toujours à un emplacement connu), puis envoie un paquet UDP IPv6 pour l’invoquer. Cela transfère le contrôle à une chaîne de programmation orientée retour (assemblant des fragments de code du noyau existants pour exécuter une logique arbitraire), et la dernière étape inverse les droits d’accès sur le core_pattern paramètre qui détermine quel programme s'exécute lorsqu'un processus plante, de sorte que le gestionnaire de plantage de l'attaquant s'exécute en tant que root.

Les fonctions concernées sont les suivantes : remove_waiter(), rt_mutex_start_proxy_lock(), et rt_mutex_adjust_prio_chain() dans kernel/locking/rtmutex.c. Ce bogue est un « use-after-free » dans la pile du noyau, entraînant une élévation de privilèges locaux. Il convient de s’attarder un instant sur le terme « pile » : la plupart des bogues de type « use-after-free » exploitables corrompent des objets du tas, dont la structure est relativement facile à manipuler. La récupération d’un objet libéré spécifique pile Une fenêtre dont le contenu est contrôlé est plus difficile à mettre en place et moins courante, ce qui explique en partie pourquoi cette faille est à la fois intéressante et, entre les mains d’un chercheur, reste fiable.

Ce que modifie le correctif « Upstream »

La correction principale se résume à une seule ligne de code. Avant l'application du correctif, la procédure de rollback en cas de blocage mutuel effaçait l'enregistrement de blocage du mauvais thread. Après cela, remove_waiter() efface waiter->task->pi_blocked_on (le véritable bilan du serveur) plutôt que current->pi_blocked_on (celle du programme de déplacement), de sorte que la fonction de dévidage ne laisse plus de thread actif pointant vers de la mémoire de pile libérée.

D'un point de vue conceptuel :

Before:  deadlock rollback → clear the mover's record → real waiter left pointing at freed memory → use-after-free
After:   deadlock rollback → clear the real waiter's record → nothing left dangling

Le commit en amont est 3bfdc63936dd (« rtmutex : utiliser waiter::task à la place de current dans remove_waiter() »). Une modification ultérieure, 74e144274af3, a été suivie séparément sous le numéro CVE-2026-53166, mais a ensuite été annulée en amont en raison d’une régression. Elle ne doit pas être considérée comme un deuxième correctif obligatoire pour GhostLock.

Comme il s'agit d'une modification mineure et autonome du chemin de verrouillage, qui n'entraîne aucune modification de la structure des données, ce correctif est un bon candidat pour une application sans redémarrage sur toutes les familles de noyaux.

Qui est concerné ?

GhostLock affecte les systèmes Linux compilés avec CONFIG_FUTEX_PI=y, qui est la configuration par défaut de toutes les principales distributions. Le code vulnérable a été introduit lors du commit 8161239a8bcc sous Linux 2.6.39-rc1 (mai 2011), et la plage de versions concernées s'étend jusqu'à la version v7.1-rc1. Dans la pratique, l'impact est pratiquement universel : tout noyau de cette plage compilé avec le PI futex.

Problème confirmé, déclenchement et attaque DoS locale reproduits par l'équipe KernelCare à l'aide du PoC public :

• Debian 13 (problème désormais résolu, voir ci-dessous)
• Debian 12 : vulnérable et pas encore corrigée
• Debian 11, vulnérable et sans errata pour l'instant
• Enterprise Linux 7 : reproduction de l'attaque par déni de service (DoS)
• Enterprise Linux 10 : reproduction de l'attaque par déni de service (DoS)

Droits root sur toute la chaîne : le chercheur a démontré publiquement qu’il était possible d’obtenir les droits root avec une fiabilité d’environ 97 %. Le composant d’exploitation utilisé à des fins malveillantes est spécifique à chaque cible et intègre dans son code source des décalages mémoire propres à chacune d’entre elles. Notre vérification, menée sur plusieurs distributions, a testé le déclencheur et la vulnérabilité « use-after-free », mais pas l’obtention des droits root spécifiques à chaque cible sur chaque distribution. On peut raisonnablement supposer que tout noyau affecté est exploitable par un attaquant motivé pour obtenir les droits root, et ne se limite pas à une simple attaque par déni de service (DoS).

La situation d'Enterprise Linux nécessite une attention particulière. Au 8 juillet, la page CVE publique de Red Hat répertorie tous les noyaux RHEL (6, 7, 8, 9 et 10, y compris la version temps réel kernel-rt) comme « Affecté », avec un niveau de gravité « Important », et aucune errata n'ayant encore été publiée. Cette page a été modifiée au cours de la journée : plus tôt dans la journée du 8 juillet, elle indiquait que RHEL n'était pas vulnérable, et toute interprétation initiale selon laquelle « EL n'était pas affecté » reposait sur cette version désormais obsolète. Il s'agit là d'un cas où le fait de lire l'avis une seule fois et de passer à autre chose aurait conduit à une conclusion erronée.

Le correctif technique de Red Hat a déjà été intégré discrètement dans CentOS Stream (la version en préversion continue des prochains noyaux RHEL). Le correctif a été appliqué à Stream 9 dans kernel-5.14.0-716.el9 et était vulnérable à kernel-5.14.0-699.el9. Le flux 10 a été corrigé dans kernel-6.12.0-239.el10 et était vulnérable à kernel-6.12.0-224.el10. Étant donné que CloudLinux 9 et 10 s'appuient sur les noyaux AlmaLinux et EL9/EL10, ce correctif Stream s'applique à ces versions ; il suffit donc de vérifier si le noyau général que vous utilisez actuellement se situe du côté « corrigé » ou du côté « vulnérable » de la frontière entre les noyaux. Les limites pour EL7 et EL8 ne sont pas encore confirmées.

Agir dès maintenant

Soyons clairs : il n'existe pas de mesure de protection simple, générale et applicable à l'ensemble de l'hôte au niveau de l'exécution.

La seule condition préalable pour que le bug se produise est CONFIG_FUTEX_PI, et il s'agit d'une option de compilation pour laquelle il n'existe aucun paramètre d'exécution. Elle est requise par les mutex à héritage de priorité de la glibc ; elle ne peut donc pas être désactivée sur un noyau de production en cours d'exécution sans perturber le fonctionnement des programmes de l'espace utilisateur qui dépendent de ces verrous. Il n'y a ni module à mettre sur liste noire ni paramètre à modifier.

Il reste donc les correctifs et un levier spécifique à chaque charge de travail.

Conteneurs et charges de travail en environnement isolé. Une politique seccomp (fonctionnalité de Linux permettant de filtrer les appels système qu'un programme est autorisé à effectuer) qui bloque les opérations d'héritage de priorité futex, FUTEX_LOCK_PI, FUTEX_WAIT_REQUEUE_PI, et FUTEX_CMP_REQUEUE_PI, désactive le déclencheur. Un filtre performant doit également prendre en compte les variantes, le futex_time64 les appels système et les numéros d'appels système spécifiques à l'architecture, ainsi que FUTEX_LOCK_PI2 sur les noyaux plus récents, ou bien ce blocage peut être contourné. L'inconvénient est que cela perturbe toute charge de travail utilisant des mutex à héritage de priorité ; il est donc recommandé de procéder à des tests avant le déploiement. C'est également ce mécanisme qui rend réelle la notion d'« évasion de conteneur » : un code non privilégié à l'intérieur d'un conteneur peut exploiter ce bogue, à moins que le moteur d'exécution ne filtre déjà ces opérations futex.

Partout ailleurs. Il n'existe aucune mesure de protection à l'échelle de l'hôte, à l'exception de l'application de la mise à jour du noyau fournie par le fournisseur ou du correctif KernelCare ne nécessitant pas de redémarrage.

C'est le moment de prendre une décision. Si vous utilisez des conteneurs ou des environnements isolés et que vous pouvez tolérer la perte des verrous d’héritage de priorité, déployez le filtre seccomp comme mesure provisoire en attendant de mettre en place la véritable solution. Pour les hôtes à usage général, la seule véritable solution est un noyau corrigé ou un correctif sans redémarrage ; donnez donc la priorité à ces mesures et isolez toute exécution locale non fiable jusqu’à ce que l’une d’elles soit mise en place. Donnez la priorité aux mises à jour déjà disponibles pour Debian 13 et EL9, ainsi qu’aux versions spécialisées d’Ubuntu 24.04, Proxmox VE 8 et AlmaLinux, et utilisez la branche « testing » le cas échéant pour Debian 12 et EL10 tant que leur passage vers la branche « production » n’est pas effectif.

Liste de contrôle des mesures correctives prioritaires

1. Enregistrez ce problème sous la référence CVE-2026-43499 (GhostLock) et vérifiez que le noyau en cours d'exécution ou le correctif « patchlivepatch » sans redémarrage inclut le correctif principal, 3bfdc63936dd. La modification suivante, référencée sous la référence CVE-2026-53166, a été annulée en amont et n'est pas nécessaire pour confirmer la couverture de GhostLock.
2. Traitez chaque noyau compris entre les versions 2.6.39-rc1 et 7.1-rc1, compilé avec CONFIG_FUTEX_PI considéré comme concerné jusqu’à preuve du contraire.
3. Donnez la priorité aux hôtes pour lesquels l'isolation locale constitue la frontière de sécurité : hébergements mutualisés, nœuds multi-locataires, environnements d'exécution CI, ainsi que les hôtes de conteneurs et de développement exécutant du code non fiable.
4. Pour Enterprise Linux, vérifiez de quel côté de la frontière entre noyaux corrigés et noyaux vulnérables se situe chaque hôte, plutôt que de vous fier à la lecture d'un seul avis de sécurité. Le flux 9 a été corrigé à kernel-5.14.0-716.el9, le flux 10 est fixé à kernel-6.12.0-239.el10; les limites des zones EL7 et EL8 n'ont pas encore été confirmées.
5. Si vous ne pouvez pas appliquer le correctif immédiatement et que la charge de travail le permet, appliquez un filtre seccomp bloquant les opérations d'héritage de priorité futex dans les conteneurs et les bacs à sable.
6. Ne pas désactiver CONFIG_FUTEX_PI sur un noyau en cours d'exécution ; cela perturbe le fonctionnement des mutex à héritage de priorité de la glibc et ne constitue pas une mesure d'atténuation prise en charge.
7. Appliquez dès maintenant les correctifs disponibles pour les versions spécialisées de Debian 13, EL9, Ubuntu 24.04, Proxmox VE 8 et AlmaLinux, et utilisez le flux « testing » pour Debian 12 et EL10 tout en continuant à suivre Debian 11, Amazon Linux 2023 et EL7 à mesure que les correctifs sont publiés.
8. À la recherche de core_pattern les modifications, les avertissements du noyau concernant « rtmutex-path » et les acquisitions de privilèges inexpliquées, et considérer que des hachages de fichiers « propres » ne constituent pas une preuve suffisante concernant l'hôte.
9. Appliquez un noyau fourni par le fournisseur et redémarrez le système, ou utilisez le correctif « sans redémarrage » de KernelCare pour le noyau actuellement en cours d'exécution, en donnant la priorité aux hôtes les plus difficiles à redémarrer.

Détection

GhostLock ne laisse aucune signature fiable sur le disque. La corruption se produit dans la mémoire du noyau, et l'étape finale documentée consiste à modifier un paramètre du noyau plutôt qu'à altérer des fichiers ; ainsi, les outils de vérification de l'intégrité des fichiers peuvent rester intacts après l'exploitation. La détection repose donc sur l'analyse comportementale. Les indices suivants sont tirés de la chaîne d'exploitation publiée ; chacun d'entre eux constitue un indice, et non une preuve :

• Modifications inattendues apportées à /proc/sys/kernel/core_pattern, ou à ses autorisations, notamment un gestionnaire qui exécute un programme externe en cas de plantage. La chaîne publique finit par exploiter core_pattern pour accéder au compte root.
• Processus non privilégiés exécutant des boucles serrées d'opérations futex d'héritage de priorité (FUTEX_LOCK_PI, FUTEX_WAIT_REQUEUE_PI, FUTEX_CMP_REQUEUE_PI) sur plusieurs threads, ce qui correspond à la mise en place du scénario de blocage.
• Erreurs ou avertissements du noyau dans le code rtmutex (mutex en temps réel), aux alentours de remove_waiter(), rt_mutex_start_proxy_lock()ou rt_mutex_adjust_prio_chain(), sans qu'aucun défaut matériel correspondant ne soit détecté.
• Utilisation de PR_SET_MM_MAP par des processus qui n'ont aucune raison légitime de réécrire leur propre structure mémoire, peu de temps après l'événement susmentionné.
• Un compte ou un service local acquérant des privilèges peu après une série d'instabilités liées à futex et rtmutex, sans qu'aucun événement sudo ou de connexion ne corresponde à ces événements.

Consulter les messages récents du noyau :

journalctl -k --since "24 hours ago" | grep -Ei 'rtmutex|pi_blocked|remove_waiter|BUG|WARNING'

L'absence de ces messages ne prouve pas qu'un hôte ait été mis à jour ou qu'il ne soit pas compromis. Un attaquant avisé peut éviter de déclencher une alerte, et il se peut tout simplement qu'une faille n'ait pas encore été exploitée. Si du code local non fiable ou partiellement fiable s'est exécuté sur un hôte affecté pendant la période d'exposition, considérez que cet hôte mérite un examen plus approfondi (notamment en vérifiant la présence de nouveaux comptes, de modifications dans la configuration d'authentification et de services inattendus), plutôt que de considérer les hachages de fichiers intacts comme une preuve de sécurité.

Pourquoi GhostLock est-il si important ?

GhostLock est une faille permettant l'escalade de privilèges en local, et non l'exécution de code à distance. Personne ne peut prendre le contrôle de votre serveur depuis Internet en s'appuyant uniquement sur cette faille. Pour les environnements réellement touchés, c'est une maigre consolation.

L'hébergement mutualisé exécute le code des clients. Les runners CI exécutent tout ce que leur a demandé la dernière pull request. Les conteneurs et les nœuds Kubernetes exécutent des charges de travail à différents niveaux de confiance, et les hôtes multi-locataires existent précisément pour isoler les locataires les uns des autres. Dans chacun de ces cas, une élévation de privilèges locale est l'événement que l'ensemble de la conception vise à empêcher. Elle transforme un code qui était autorisé à s'exécuter en un code s'exécutant en tant que root, là où il n'aurait jamais dû l'être.

La raison pour laquelle il est facile de se tromper est aussi celle pour laquelle cela est dangereux. Trois signaux plausibles indiquent tous que la situation est « sûre », mais tous induisent en erreur. L’ancienneté de la faille pourrait faire penser à une pièce de musée, alors qu’elle est accessible aujourd’hui sur un noyau par défaut. La fonctionnalité futex semble être une fonctionnalité de niche, alors qu’elle est intégrée à pratiquement toutes les distributions et utilisée par les verrous standard de la glibc. Et un avis consulté une seule fois le matin du 8 juillet aurait pu indiquer que RHEL n’était pas vulnérable, quelques heures avant que cette même page ne soit mise à jour pour répertorier tous les noyaux RHEL comme affectés. Si vous vous fiez à l’un de ces éléments, vous classerez un hôte vulnérable comme sûr.

GhostLock est exactement le genre de faille pour laquelle les correctifs sans redémarrage ont été conçus. La modification en amont est disponible, mais cela ne protège pas un système en cours d’exécution : le fournisseur doit la rétroporter, vous devez installer le paquet, et la machine doit démarrer avec le nouveau noyau. Sur les parcs de serveurs multi-locataires et de conteneurs, cette dernière étape peut prolonger l’exposition résiduelle à une faille « local-root » connue pendant des semaines, et c’est précisément sur les hôtes les plus exposés que cela pèse le plus lourdement.

Cette modification est un bon candidat pour un correctif applicable sans redémarrage : il s'agit d'une petite correction autonome au niveau du chemin de verrouillage, qui n'implique aucune modification de la structure des données ni aucun état persistant à transférer. KernelCare porte le correctif principal de GhostLock, 3bfdc63936dd, dans le noyau en cours d'exécution. À noter qu'il s'agit d'un bogue affectant uniquement le noyau, sans composant lié aux bibliothèques de l'espace utilisateur.

État de la version des correctifs en direct (KernelCare) au 10 juillet 2026, 17 h 00 UTC.

Fil d'actualité principal :

• Famille EL9 : RHEL 9, AlmaLinux 9, Oracle Linux 9, Rocky Linux 9
• AlmaLinux 9 LTS et AlmaLinux 9 FIPS 9.6
• Ubuntu 24.04
• Proxmox VE 8

Flux de test :

• Famille EL10 : RHEL 10, AlmaLinux 10, Rocky Linux 10, Oracle Linux 10
• Debian 12

Corrigé et publié par le fournisseur :

• Debian 13

En attente ou pas encore sorti :

• Amazon Linux 2023 : version compilée, mais pas encore disponible
• Debian 11 : couverture en attente
• EL7 : couverture en attente
• EL6 : faible priorité

Les informations relatives au correctif KernelCare font uniquement référence à la vulnérabilité CVE-2026-43499 ; le fait que cette vulnérabilité soit répertoriée dans la base CVE confirme que GhostLock a été corrigé. La modification suivante, référencée sous le numéro CVE-2026-53166, a été annulée en amont en raison d'une régression et n'est pas nécessaire pour vérifier la couverture.

Appliquez-le à partir du flux de test dès qu'une balise K est disponible :

kcarectl --update --prefix test

Appliquer à partir du flux de production une fois la mise à jour effectuée :

kcarectl --update

Vérifiez la correspondance avec les CVE de GhostLock plutôt que de vous fier à la date de compilation :

kcarectl --info | grep kpatch-build-time      # build dated 2026-07-08 or later
kcarectl --patch-info | grep 'CVE-2026-43499'

La date de compilation à elle seule ne prouve rien, car un noyau compilé après la mi-avril n'intègre pas automatiquement le correctif GhostLock. Vérifiez directement le mappage CVE, l'erratum du fournisseur, le code source ou l'état du correctif « rebootless-patch ».

GhostLock transforme une faille de verrouillage vieille de quinze ans en une faille de la barrière de privilèges locale. Pour les parcs informatiques qui ne peuvent pas supporter de redémarrages d'urgence, un correctif sans redémarrage comble cette faille dans le noyau en cours d'exécution sans mettre les nœuds hors service ni interrompre les charges de travail.

Procurez-vous KernelCare dès aujourd’hui →

Chronologie

Références

• IonStack, 2e partie : GhostLock, Nebula Security, 7 juillet 2026 : https://nebusec.ai/research/ionstack-part-2/
• Entrée dans la liste des bogues, CVE-2026-43499 : https://nebusec.ai/buglist/CVE-2026-43499
• Démonstration publique (PoC), CyberMeowfia/IonStack/CVE-2026-43499 : https://github.com/NebuSec/CyberMeowfia/tree/main/IonStack/CVE-2026-43499
• Correction en amont 3bfdc63936dd (« rtmutex : utiliser waiter::task au lieu de current dans remove_waiter() ») : https://git.kernel.org/linus/3bfdc63936dd4773109b7b8c280c0f3b5ae7d349
• Annulation de la modification 74e144274af3 (CVE-2026-53166 ; annulée par la suite en amont en raison d'une régression) : https://git.kernel.org/linus/74e144274af39935b0f410c0ee4d2b91c3730414
• Commit à l'origine d'un bug 8161239a8bcc (« rtmutex : simplification de l'algorithme PI et attribution du verrou à la tâche ayant la priorité la plus élevée »), inclus dans la version v2.6.39-rc1
• Red Hat CVE-2026-43499 (noyau RHEL 6-10 / kernel-rt répertoriés comme affectés, niveau de gravité « Important », BZ 2480453) : https://access.redhat.com/security/cve/cve-2026-43499
• Corrections silencieuses de CentOS Stream : cs9 4e5a31ae1fa9, cs10 7bba8926cefe
• Presse : The Hacker News, « Une faille GhostLock vieille de 15 ans permet l'accès root… » : https://thehackernews.com/2026/07/15-year-old-ghostlock-flaw-enables-root.html