La faille en deux phrases
Il s’agit d’un use-after-free dans le sous-système de verrouillage du noyau, sur le chemin d’héritage de priorité des futex — la mécanique derrière les mutexPTHREAD_PRIO_INHERIT de la glibc. Une étape de nettoyage dans remove_waiter() efface la comptabilité du mauvais thread et laisse un thread vivant pointer sur de la mémoire déjà libérée.
L’objet libéré se trouve sur la pile du noyau, et non sur le tas où vit l’immense majorité des bugs de cette famille. C’est ce détail qui rend l’exploitation aussi fiable.
Le seul prérequis est CONFIG_FUTEX_PI=y, activé par défaut dans toutes les distributions majeures. Le code a été introduit dans Linux 2.6.39-rc1 en mai 2011 et est resté vulnérable jusqu’à la v7.1-rc1 : autant dire tous les noyaux de production des quinze dernières années.
Pourquoi celle-ci sort du lot
Les élévations de privilèges locales sont fréquentes et finissent d’ordinaire en bas de la pile des priorités. Deux propriétés changent la donne ici. L’exploit est public et il fonctionne. La chaîne complète publiée atteint root en cinq secondes environ, avec une fiabilité de l’ordre de 97 %. Ce n’est pas une preuve de concept qui exige un noyau précis et un vent favorable : c’est un outil qui marche. Il sort des conteneurs. Un processus non privilégié dans un conteneur obtient root sur l’hôte. Si vous faites tourner des charges tierces ou non auditées sur un nœud partagé, l’isolation sur laquelle vous comptez n’est pas là.Mesurer votre exposition
La question n’est pas le score CVSS — il vaut 7,8, et ce chiffre vous apprend peu de chose ici. La question est : qui peut exécuter du code sur votre machine ?
Le schéma mérite d’être noté : la faille exige un point d’appui local. Elle n’est pas exploitable à distance en elle-même. Mais elle transforme n’importe quel appui modeste — une application web compromise, un compte peu privilégié fuité, une dépendance hostile dans un build — en contrôle total de la machine.
Il n’y a pas de contournement
C’est le point sur lequel beaucoup se trompent. Le bulletin de Red Hat le dit sans détour : aucun paramètre noyau à chaud, aucun module à désactiver ne corrige la faille.CONFIG_FUTEX_PI est compilé dans les noyaux standards et ne se désactive pas à l’exécution.
Contrairement à une faille cantonnée à un module chargeable, vous ne pouvez pas gagner une semaine avec une liste noire modprobe. Vous corrigez et vous redémarrez, ou vous restez vulnérable.
Appliquer le correctif
Debian, Ubuntu et dérivées
AlmaLinux, Rocky Linux et RHEL
Le bulletin de Red Hat couvre RHEL 6 à 10, ainsi qu’OpenShift, OpenStack Platform, RHEL CoreOS et tous les produits bâtis sur le noyau RHEL.
Vérifier le noyau réellement actif
Installer le paquet n’est pas l’exécuter. Contrôlez après le redémarrage :Sur un cluster Kubernetes, un nœud n’est corrigé qu’une fois redémarré. Drain, reboot, uncordon, un nœud à la fois : un paquet à jour sur un nœud non redémarré exécute toujours le noyau vulnérable.
Chronologie
La gestion a été propre, et cela mérite d’être souligné : la faille a été signalée le 18 avril par Nebula Security, corrigée en amont deux jours plus tard dans le commit3bfdc63936dd, rétroportée le 4 mai, et divulguée publiquement seulement le 7 juillet. Les distributions avaient leurs correctifs prêts avant la publication des détails.
L’exploit a suivi dans la journée qui a suivi la divulgation. Si vos serveurs n’ont pas redémarré depuis début juillet, considérez que la fenêtre est restée ouverte depuis.