GhostLock : une évasion de conteneur qui brise l'hypothèse du bac à sable des agents

De quoi s’agit-il ?

Le 8 juillet 2026, Nebula Security a divulgué GhostLock, une use-after-free dans le code de mutex temps réel (rtmutex) du noyau Linux, sur le chemin d’héritage de priorité. Un utilisateur local non privilégié peut l’exploiter pour obtenir le root — et, point crucial pour quiconque exécute des agents IA, la faille s’exploite depuis l’intérieur d’un conteneur pour s’évader vers l’hôte. Le bug a été introduit en 2011 (Linux 2.6.39) et est resté inaperçu pendant une quinzaine d’années, jusqu’à ce qu’un outil d’analyse automatisé le mette au jour. Il est désormais corrigé dans la branche principale (commit 3bfdc63936dd, Linux 7.1) et les distributions ont commencé à publier des correctifs la même semaine ; AlmaLinux a publié son avis le 9 juillet.

Nous ne traitons pas ce sujet comme une curiosité de sécurité noyau. Nous le traitons parce que l’isolation par conteneur est l’hypothèse porteuse sous presque tous les bacs à sable d’exécution de code des agents — la boîte où un agent de code exécute des scripts générés, où un agent outillé évalue du code non fiable, où un runner CI exécute une tâche rédigée par une IA. GhostLock est un moyen fiable et sans privilège de sortir de cette boîte, et un exploit fonctionnel est déjà public.

Comment ça marche

La faille réside dans kernel/locking/rtmutex.c, sur le chemin d’héritage de priorité des futex. Une fonction de nettoyage (remove_waiter()) suppose que le waiter qu’elle nettoie appartient toujours à la tâche en cours d’exécution. Dans le chemin de requeue FUTEX_CMP_REQUEUE_PI, le noyau doit parfois faire marche arrière pour le compte d’un autre thread endormi après avoir détecté un cycle de blocage et effectué un rollback avec -EDEADLK. Pendant ce rollback, il efface le pi_blocked_on de la mauvaise tâche, laissant un pointeur pendouillant vers de la mémoire de pile noyau déjà libérée — une use-after-free de pile.

Pour la déclencher, un attaquant dispose trois futex et un ensemble de threads coordonnés en un interblocage par inversion de priorité, puis réoccupe la trame de pile libérée avec une structure waiter forgée. À partir de là, le compte rendu public enchaîne une écriture contrainte en lecture/écriture arbitraire du noyau, détourne le flux de contrôle et aboutit au root. Nebula indique que l’exploit est fiable à 97 % et s’exécute en environ cinq secondes sur sa machine de test, et précise que Google a attribué à l’équipe 92 337 $ via le programme kernelCTF. La seule condition préalable est de pouvoir exécuter des appels de threading ordinaires en tant que processus local — aucune capacité particulière, aucune configuration inhabituelle. L’exposition est large car le chemin ne dépend que de CONFIG_FUTEX_PI, activé sur pratiquement tous les noyaux de distribution. Nous omettons les primitives d’exploitation ; le mécanisme ci-dessus provient entièrement de la divulgation publique.

Pourquoi c’est important

Pour une plateforme d’agents, « l’attaquant a besoin d’un point d’appui local » n’est pas la garantie qu’on croit. Tout l’intérêt d’un bac à sable d’exécution de code est d’accorder délibérément un point d’appui local à du code non fiable et de compter sur la frontière du conteneur pour l’y maintenir. Un agent de code victime d’une injection de prompt, une compétence malveillante ou une fixture de test fournie par un attaquant qui atteint l’exécution de code dans le conteneur se trouve déjà exactement dans la position dont GhostLock a besoin. Dès lors, l’évasion conteneur-vers-hôte transforme « l’agent a exécuté quelque chose qu’il n’aurait pas dû dans son bac à sable » en « le bac à sable de l’agent n’existe plus ». Sur une infrastructure partagée et multi-tenant — runtimes d’agents hébergés, CI, backends de notebooks — cela signifie passer de la tâche d’un tenant à l’hôte, et potentiellement à tous les autres tenants qui s’y trouvent.

Deux remarques de contexte renforcent le propos sans l’exagérer. D’abord, GhostLock est la moitié noyau d’une chaîne que Nebula appelle IonStack : associée à une faille d’évasion de bac à sable de navigateur, un simple clic sur un lien malveillant a été mené jusqu’au root sur Android — rappel qu’un bug « local seulement » devient distant lorsqu’il est greffé sur une étape antérieure. Ensuite, le bug a été trouvé par un outil d’analyse piloté par IA passant au peigne fin de vieux rouages du noyau, dans une série 2026 de découvertes d’élévation de privilège similaires sur les futex/verrous. Les limites honnêtes : la faille est notée 7,8 (élevée, pas critique) précisément parce qu’elle exige une exécution locale, aucune exploitation dans la nature n’est connue à ce jour, et des noyaux corrigés existent. C’est la disponibilité publique de l’exploit qui accélère le calendrier.

Défenses

La leçon pour les opérateurs d’agents est que la frontière du conteneur est un contrôle qui peut céder ; elle ne devrait donc jamais être la seule chose entre l’exécution non fiable et l’hôte :

• Patchez le noyau en priorité sur chaque hôte qui exécute des charges d’agents. Installez le noyau courant de votre distribution, pas seulement le premier build corrigé — le correctif initial a introduit un bug de crash distinct (voir Status), si bien que les premiers builds peuvent être incomplets. Priorisez les runtimes d’agents multi-tenant, les runners CI et les backends de code/notebooks.
• Ne traitez pas les conteneurs comme une frontière de sécurité à eux seuls. Placez une seconde couche sous l’exécution de code des agents — un bac à sable basé sur la virtualisation (microVM / type gVisor) ou une VM dédiée et jetable par tâche non fiable — pour qu’une évasion noyau n’atteigne pas immédiatement un hôte partagé.
• Réduisez ce qu’un bac à sable compromis peut atteindre. N’accordez aux environnements d’exécution d’agents aucun identifiant cloud ambiant, aucun montage d’hôte et aucun chemin réseau latéral ; supposez que le bac à sable peut être percé et limitez le rayon d’impact en conséquence.
• Durcissez la configuration de build. RANDOMIZE_KSTACK_OFFSET et STATIC_USERMODE_HELPER rendent cet exploit précis plus difficile. Ce sont des atténuations, pas des correctifs, et elles ne remplacent pas le patch.
• Surveillez l’élévation de privilège, pas seulement les anomalies de prompt. La détection à l’exécution sur les hôtes d’agents doit guetter l’élévation au niveau noyau et les transitions inattendues vers root, pas uniquement les signaux côté modèle — l’étape nuisible se produit ici bien en dessous du LLM.

Status

Élément	Détail
Nom	GhostLock
Référence	CVE-2026-43499 (NVD) — CVSS 7,8 (élevée)
Type	Use-after-free de pile, rtmutex / héritage de priorité des futex (FUTEX_CMP_REQUEUE_PI)
Impact	Root local non privilégié et évasion conteneur-vers-hôte
Introduite	Linux 2.6.39 (2011) ; ~15 ans inaperçue
Corrigée	Commit principal 3bfdc63936dd, Linux 7.1 ; backports distributions à partir de la semaine du 7 juil. 2026
Découverte	Nebula Security, via l’outil d’analyse piloté par IA « VEGA » ; signalée à security@kernel.org
Exploit	PoC public ; fiabilité ~97 %, ~5 s ; récompense Google kernelCTF de 92 337 $
Réserve	Un correctif de suivi est recommandé pour une régression de crash distincte (CVE-2026-53166) introduite par le patch initial
Dans la nature	Aucune exploitation connue à la date de divulgation (8 juil. 2026)