j-jaeyoung/bad-epollExploit d'élévation de privilèges du noyau Linux pour CVE-2026-46242, une condition de concurrence de type utilisation après libération dans epoll, avec un accès root fiable à 99% sur les ordinateurs de bureau, les serveurs et les appareils Android.
Un processus non privilégié escaladant vers root sur Google kernelCTF.
Bad Epoll (CVE-2026-46242) est une use-after-free par condition de course dans le sous-système epoll du noyau Linux. Ce bug permet à un processus non privilégié de devenir root, non seulement sur les postes de travail et serveurs Linux, mais aussi sur les appareils Android.
Bad Epoll a été signalé et exploité par Jaeyoung Chung comme une soumission 0-day à Google kernelCTF, qui récompense une exploitation du noyau Linux avec 71 337 $+.
[!NOTE] L'IA d'Anthropic, Mythos, a trouvé un autre bug de course dans le même code epoll mais a manqué Bad Epoll.
Un bug rare qui peut rooter Android. La plupart des bugs d'escalade de privilèges Linux ne peuvent pas rooter Android du tout. Copy Fail et ses variantes, par exemple, nécessitent des modules qu'Android ne charge jamais. Sur les quelque 130 vulnérabilités exploitées sur Google kernelCTF, seulement une dizaine sont candidates pour rooter Android. Bad Epoll en fait partie.
Aucune coupure d'urgence. Copy Fail et ses variantes peuvent être neutralisés en déchargeant leurs modules vulnérables, mais epoll n'a pas cette option. C'est une fonctionnalité centrale du noyau sur laquelle le système d'exploitation, les services réseau et les navigateurs comptent tous. La seule façon de le réparer est d'appliquer le correctif.
Fenêtre de course minuscule, mais l'attaque est fiable à 99 %. La fenêtre de course du bug ne fait qu'environ six instructions de large, et une tentative normale ne l'atteint presque jamais. L'exploitation élargit cette fenêtre et exécute une boucle de réessai qui ne plante jamais le noyau. Le résultat est une exploitation fiable à 99 %, comme le décrit l'aperçu de l'attaque ci-dessous.
Un seul commit en 2023 a introduit deux conditions de course distinctes dans le code epoll, seulement environ 2 500 lignes au total. Les deux se sont avérés être des bugs critiques pouvant conduire à une escalade de privilèges.
Le premier a été trouvé par Mythos d'Anthropic et signalé comme CVE-2026-43074. Ce résultat est impressionnant en soi, car les bugs de course dans le noyau sont réputés difficiles à trouver. Il a montré la capacité d'un modèle d'IA de pointe à trouver des bugs de course. Un chercheur indépendant a ensuite soumis une exploitation 1-day pour kernelCTF.
L'autre course est Bad Epoll, que Mythos a manqué. Étant donné que Mythos a trouvé le premier bug dans ce petit chemin de code epoll, il a probablement examiné la même zone avec une profondeur significative. Nous ne pouvons pas savoir exactement pourquoi il a manqué Bad Epoll, mais deux facteurs ont probablement rendu sa découverte difficile.
La fenêtre de course est minuscule. Elle ne fait qu'environ six instructions de large, donc l'entrelacement exact des threads est difficile à imaginer même en regardant le code vulnérable.
Il y avait peu de preuves à l'exécution. Après la correction de CVE-2026-43074, la use-after-free de Bad Epoll ne déclenche généralement pas KASAN, le principal détecteur d'erreurs mémoire du noyau. Sans ce signal, Mythos n'a peut-être pas eu assez de confiance pour le signaler comme un vrai bug.
Bad Epoll a aussi été difficile à corriger. Le premier correctif des mainteneurs n'a pas entièrement résolu le problème, et un correctif correct n'a atterri que deux mois après le signalement initial du bug. C'est long pour un noyau qui traite généralement les problèmes de sécurité avec urgence.
Dans l'ensemble, Bad Epoll montre à quel point les conditions de course sont difficiles à chaque étape. Elles sont difficiles à trouver même pour un modèle de pointe, difficiles à corriger correctement et, comme le montre la section suivante, difficiles à exploiter de manière fiable. Cela suggère également une direction de recherche en vulnérabilités qui reste intéressante à explorer en présence de modèles d'IA de pointe : découvrir l'impact réel sur la sécurité derrière des conditions temporelles étroites et des preuves faibles.
Voici un aperçu de haut niveau de l'attaque, pour les curieux.
Deux objets epoll liés. Fermer les deux à la fois déclenche la course.
Deux des chemins de fermeture d'epoll s'exécutent en même temps et entrent en collision. L'un libère un objet pendant que l'autre écrit encore dedans, et c'est la use-after-free (UAF).
La fenêtre de course, et comment l'exploitation la pilote.
L'exploitation utilise quatre objets epoll regroupés en deux paires. Une paire déclenche la course, tandis que l'autre devient la victime. À partir de là, l'exploitation transforme l'écriture UAF de 8 octets en une UAF sur un objet fichier, et utilise une attaque cross-cache pour contrôler complètement le contenu du fichier.
Transformer le bug en une lecture arbitraire de la mémoire du noyau via /proc/self/fdinfo.
Avec ce contrôle, l'exploitation obtient une lecture arbitraire de la mémoire du noyau via /proc/self/fdinfo. Enfin, elle détourne le flux de contrôle et exécute une chaîne ROP pour obtenir un shell root.
Plus de détails sont disponibles dans le rapport d'exploitation complet et le code.
Parce qu'epoll ne peut pas être désactivé, Bad Epoll n'a pas de contournement simple. Le seul remède est d'appliquer le correctif.
