GhostLock donne root en cinq secondes via un use-after-free de quinze ans dans rtmutex
CVE-2026-43499, baptisée GhostLock, est un use-after-free dans le code d’héritage de priorité de rtmutex, présent depuis le noyau 2.6.39 et exploitable par n’importe quel processus local non privilégié. Le correctif est dans la 7.1, mais deux mois après le PoC, quelques angles morts comme le kernel-rt de RHEL 9 subsistent : vérifiez votre version et bloquez les futex PI en attendant.
7 juillet 2026. Nebula Security publie l’analyse de GhostLock (CVE-2026-43499), un use-after-free dans le code d’héritage de priorité de rtmutex. 8 juillet 2026. Un proof-of-concept public obtient un shell root en cinq secondes, avec 97 % de fiabilité. Septembre 2026. Red Hat accélère encore la publication des correctifs dans le bulletin RHSB-2026-010. Pourquoi c’est important : le bug dort dans le noyau depuis 2011, n’exige aucun privilège, et s’évade d’un conteneur vers l’hôte.
Le bug : un use-after-free sur la pile du noyau
La faille vit dans kernel/locking/rtmutex.c, au cœur de la fonction remove_waiter(), qui déroule une demande de verrou quand une opération doit être annulée. Cette routine part du principe que le thread qui nettoie possède toujours la demande qu’il détruit.
Ce principe se brise sur le chemin FUTEX_CMP_REQUEUE_PI. Lors d’une requeue avec héritage de priorité, le noyau peut détecter un cycle de deadlock et appeler remove_waiter() dans un contexte où l’hypothèse ne tient plus : le verrou appartient à une autre tâche. La fonction efface alors pi_blocked_on sur la mauvaise tâche et laisse un pointeur vers de la mémoire de pile déjà libérée — un use-after-free classique.
L’exploitation consiste à récupérer cette zone libérée avec une allocation soigneusement façonnée, à y placer une structure noyau forgée, puis à déréférencer le pointeur pendant pour obtenir une écriture contrôlée. De là, le passage au root est direct. La seule condition est CONFIG_FUTEX_PI, activé par défaut dans toutes les grandes distributions : pas de privilège, pas de capacité, pas de namespace requis.
La découverte tient aussi à la méthode : Nebula Security a trouvé le bug avec VEGA, un outil d’analyse statique assisté par l’IA. Google a récompensé la soumission à hauteur de 92 337 dollars via kernelCTF. Un use-after-free de quinze ans, trouvé par une machine, résume bien la nouvelle donne du bug hunting.
L’épisode valide une tendance à prendre au sérieux : la chasse aux bugs assistée par IA commence à faire remonter des défauts vieux de plusieurs décennies que des années de revue humaine n’avaient pas vus. Ce n’est pas une accusation contre les auteurs du code — c’est le rappel que les adversaires disposent désormais d’outils qui lisent le code autrement que les auditeurs ne l’ont historiquement fait. Un use-after-free dormant depuis 2011 dans du code de verrouillage, trouvé par une machine, est le symbole de cette bascule.
Pourquoi « local » n’est pas rassurant
Les failles d’élévation de privilèges locales sont souvent reléguées au second plan parce qu’elles supposent un pied déjà dans la place. GhostLock mérite mieux.
Sur un serveur mutualisé, l’accès local est la situation de départ : chaque processus PHP d’un locataire, chaque cron, chaque compte mail compte. Une simple injection SQL ou un plugin obsolète suffit à déposer un web shell ; GhostLock transforme ce processus local en root sur l’hôte entier, pas seulement sur le compte compromis.
Les conteneurs ne sont pas à l’abri non plus. Le bug fonctionne depuis un conteneur standard, sans user namespace privilégié. La chaîne IonStack l’a démontré : des chercheurs ont enchaîné une évasion de bac à sable Firefox (CVE-2026-10702) avec GhostLock pour obtenir un compromis « page web vers noyau » sur Firefox Android. Pour un hébergeur qui exécute des charges conteneurisées, le modèle de menace s’effondre dès qu’un seul conteneur peut déclencher ce chemin.
L’état du patch, deux mois après
Le correctif amont (3bfdc63936dd, « rtmutex: Use waiter::task instead of current in remove_waiter() ») est arrivé dans la 7.1, puis a été rétroporté sur toutes les branches maintenues : 7.0.4, 6.18.27, 6.12.86, 6.6.140, 6.1.175, 5.15.212 et 5.10.261, entre mai et juillet 2026. Debian a résolu ses suites jusqu’au bullseye LTS (DLA-4717-1, le 4 août), juste avant sa fin de support.
Il reste des angles morts. Red Hat confirme que CVE-2026-43499 et son compagnon CVE-2026-53166 — un plantage introduit par le premier correctif — touchent RHEL 6 à 10 et tous les produits en couches (OpenShift, OpenStack, Virtualisation). Le suivi communautaire kimmo.cloud note que le kernel-rt de RHEL 9 n’avait pas encore reçu le correctif au dernier pointage, et qu’Amazon Linux 2, en fin de support depuis le 30 juin, ne recevra plus aucun correctif.
CVE-2026-53166 mérite une attention à part : elle découle du correctif initial, ce qui explique pourquoi le paysage de patchs a mis deux mois à se stabiliser.
Comment fermer le chemin
Le correctif du noyau est la seule remédiation complète, mais des parades intermédiaires existent.
# Vérifier la version du noyau en cours
uname -r
# RHEL 8 / 9 / 10 : appliquer le noyau corrigé puis redémarrer
dnf update kernel
reboot
# Sur CloudLinux : vérifier qu'un livepatch GhostLock est appliqué
kcarectl --patch-info | grep CVE-2026-43499Un profil seccomp qui bloque les trois opérations futex PI — FUTEX_LOCK_PI, FUTEX_WAIT_REQUEUE_PI et FUTEX_CMP_REQUEUE_PI — coupe le chemin de déclenchement sans toucher au noyau. Le coût est réel : toute application qui utilise des mutex à héritage de priorité cassera. Pour la plupart des charges web, c’est une mesure temporaire viable ; pour des services temps réel, non.
Les options de build RANDOMIZE_KSTACK_OFFSET et STATIC_USERMODE_HELPER élèvent la barre d’exploitation, mais ne corrigent pas le bug : elles ne doivent pas être traitées comme une mitigation à elles seules.
Le paradoxe du temps réel
Il y a une ironie dans le fait que le bug vive précisément dans rtmutex, le chemin du noyau réservé au temps réel et à l’héritage de priorité. Les noyaux -rt (PREEMPT_RT) sont ceux qui utilisent le plus ce code — et pourtant ce sont eux que les distributions corrigent en dernier, parce que le patchset -rt vit dans une arborescence séparée, souvent décalée de plusieurs semaines par rapport au noyau standard.
C’est ce qui explique l’angle mort documenté par kimmo.cloud : le kernel-rt de RHEL 9 attendait encore son correctif au dernier pointage, alors que le noyau standard de la même version était déjà couvert. Pour une salle de marché, un automate industriel ou tout système qui tourne sous noyau temps réel, la parade seccomp qui bloque les futex PI est précisément celle qui risque de casser l’héritage de priorité dont dépend l’application. Le temps réel cumule donc l’exposition maximale et la marge de manœuvre minimale.
Verdict
GhostLock est le rappel qu’un bug de quinze ans dans du code de verrouillage générique touche tous les noyaux, toutes les architectures, tous les hébergeurs.
Si votre noyau est antérieur aux versions corrigées (7.0.4, 6.18.27, 6.12.86, 6.6.140, 6.1.175, 5.15.212, 5.10.261), appliquez le backport et redémarrez sans attendre, puis déployez un blocage seccomp des futex PI là où la charge le permet. Si vous tournez sur RHEL 9 kernel-rt ou Amazon Linux 2, vous êtes dans un angle mort : migrez vers un noyau patché ou une distribution encore supportée, car aucun correctif n’est garanti. Et tant que ce n’est pas fait, traitez toute compromission d’application comme un événement de niveau noyau.