Infinity Core démontre que les parties « silencieuses » du noyau ne sont pas à l'abri

En bref

Aller directement à la version longue ↓

De quoi s'agit-il ? « Infinity Core » est le nom donné par Hyunwoo Kim (@v4bel) à six failles présentes dans le code central du noyau, concernant les temporisateurs CPU POSIX, la transmission des signaux, le « page table walker », les futexes, la comptabilité du cache du planificateur et l'allocateur SLUB. Kim a publié les détails et le code d'exploitation sur oss-security le 16 octobre 2026, dès l'expiration de l'embargo imposé par les distributions Linux. Aller à cette section →

Impact : Cinq de ces six failles s'accompagnent d'une démonstration publique de concept qui part d'un compte ordinaire sans privilèges et aboutit à un shell root. Kim classe également ces cinq failles parmi les « échappements de conteneur ». La sixième, dans SLUB, ne provoque pour l'instant qu'un panique du noyau. Aller à cette section →

Gravité : les notes ne reflètent pas bien la réalité. Amazon Linux attribue aux bogues liés au timer et au signal une note de 7,0 selon le CVSS 3.1, et au bogue MM une note de 6,3, tous avec un vecteur d'attaque local et une complexité d'attaque élevée. Ces notes ont été publiées avant que des exploits root fonctionnels ne soient rendus publics. Aller à cette section →

Qui est concerné : C'est Ubuntu 26.04 qui est le plus durement touché. Les exploits root liés aux failles « timer », « signal », « MM » et « futex » ont été développés et testés sur cette version. 7.0.0-30-generic noyau, et l’équipe chargée du noyau chez TuxCare a également réussi à obtenir des droits root avec ces quatre vulnérabilités sur Ubuntu 26.04. Le bogue lié au timer affecte également les noyaux EL9 et EL10, Debian 12 et 13, ainsi qu’Ubuntu 24.04, où les tests menés par TuxCare ont provoqué des plantages, mais pas l’obtention des droits root – du moins, pas encore. Les bogues liés au planificateur et à SLUB n’existent que dans la version 7.2 et les versions ultérieures. Aller à cette section →

Statut : des correctifs en amont existent pour les six vulnérabilités, et quatre des enregistrements CVE avaient déjà été rendus publics entre le 4 septembre et le 6 octobre. Les noyaux des distributions rattrapent leur retard de manière inégale. Debian, par exemple, a déjà publié des noyaux de sécurité corrigés pour « bookworm » et « trixie », tandis que Red Hat a corrigé le bogue « futex » pour RHEL 9 dès le 1er octobre. Aucun cas d’exploitation en milieu réel n’a été signalé. Il s’agit de vulnérabilités de type « n-day » pour lesquelles des exploits publics existent, et non de vulnérabilités de type « zero-day ».

À faire dès maintenant : il n'existe aucun paramètre sysctl ni module connu permettant de désactiver cette fonctionnalité. Commencez par installer des noyaux corrigés sur les hôtes Ubuntu 26.04, en priorisant ceux qui exécutent du code provenant de sources auxquelles vous ne faites pas entièrement confiance, comme les serveurs d’hébergement mutualisé, les environnements de CI et les hôtes de conteneurs multi-locataires. Si votre distribution propose déjà un correctif, installez-le et prévoyez un redémarrage. La désactivation des espaces de noms utilisateur non privilégiés ne servira à rien, car aucun de ces bogues n’en nécessite. Pour vérifier quel noyau est effectivement en cours d’exécution :

uname -r

Comparez cela avec les recommandations de votre fournisseur, et non avec les numéros de version en amont. Les noyaux des distributions intègrent les correctifs sans modifier le numéro de version de base.

Aller à cette section →

La plupart des cas d’escalade de privilèges au niveau du noyau qui font la une des journaux proviennent des mêmes domaines : les réseaux, les sockets, BPF, perf. Il s’agit de bogues accessibles uniquement via un espace de noms utilisateur sans privilèges. Depuis des années, les guides de sécurisation enseignent aux administrateurs à isoler ces espaces, et de nombreuses entreprises ont suivi ces recommandations à la lettre.

Infinity Core contourne tout cela. Kim a délibérément écarté ces zones et s'est penché sur le code de tous les processus qui s'exécutent sans que l'on y prête attention, tels que exec(), traitement des signaux, mincore() et les futexes. Le résultat : quatre failles permettant d'obtenir les droits root sur une installation Ubuntu 26.04 par défaut, une autre sur Arch Linux, et aucun paramètre sysctl ni module connu permettant de les éliminer.

Les correctifs ont déjà été intégrés en amont. Ce qui manque à de nombreux hébergeurs, c'est un noyau opérationnel qui les intègre.

Les nouveautés du 16 octobre

Kim a signalé ces failles en privé, les a traitées via la liste de diffusion « linux-distros » et les a rendues publiques une fois l’embargo levé, le 16 octobre 2026. L’article publié sur oss-security et le dépôt InfinityCore contiennent des descriptions détaillées de chaque faille ainsi que le code d’exploitation. Ce n’est d’ailleurs pas la première fois que Kim apparaît sur ce blog. C’est ce même chercheur qui avait découvert Januscape et Zapscape, les failles permettant de contourner KVM, au début de cette année.

Quatre des six CVE faisaient déjà l’objet d’enregistrements publics avant le jour de la divulgation. Le CNA du noyau a publié le CVE « futex » le 4 septembre, celui concernant la gestion de la mémoire (MM) le 11 septembre, et les CVE relatifs au timer et aux signaux le 6 octobre. Chacun d’entre eux a été publié sous un titre laconique, à la manière d’un commit, comme c’est souvent le cas pour les CVE du noyau, sans rien qui laisse présager l’arrivée d’un exploit permettant d’accéder aux privilèges root. Un CVE qui ressemble à un correctif de nettoyage est facile à mettre de côté jusqu’à la prochaine fenêtre de maintenance. Ce n’est pas le cas d’un même CVE accompagné d’un exploit root disponible sur GitHub.

Il reste encore une faille non divulguée. Kim explique que ce bug lié au chronomètre permet également d'obtenir les droits root complets sur un Samsung Galaxy S26 Ultra à partir d'une application ordinaire, et que cette faille restera confidentielle jusqu'à ce que Samsung propose un correctif ou que quelqu'un d'autre en publie un avant.

Les bogues liés au temporisateur et au signal partagent un même déclencheur, qui est pour le moins étrange. Lorsqu’un thread qui n’est pas le leader du processus appelle exec() et lorsque le processus avance suffisamment, le noyau permute les identifiants des threads afin que le thread appelant prenne le relais en tant que nouveau leader. Ces deux bogues se situent dans le code de nettoyage lié à cette permutation.

La vulnérabilité CVE-2026-98260, dite « bug du timer », nécessite qu’un timer CPU POSIX soit activé pour chaque thread sur ce thread. Si exec() si l'opération échoue après l'échange d'identifiants, le temporisateur est libéré alors que son nœud est toujours en attente d'une tâche active, et le processus de nettoyage tombe ensuite directement sur ce nœud libéré. Un cas classique d'« use-after-free ». L'exploit rendu public permet d'obtenir un shell root sur Ubuntu 26.04, et le correctif, acb03d388181, déplace le nettoyage du minuteur pour qu'il ait lieu immédiatement après de_thread() pour qu'il n'y ait plus de points en suspens quand exec() cautions.

CVE-2026-98256, le « bug du signal », est un conflit de concurrence sur un même instant. Un chemin vide les signaux en attente du leader en fin de vie sans acquérir de verrou, tandis qu’un autre suit le PID permuté et relie un sigqueue ajout à la file d’attente du nouveau leader. En corrompant les liens, une entrée survit à l’objet auquel elle appartient. L’exploit de Kim utilise cette entrée résiduelle comme oracle pour déterminer quand la mémoire libérée a été réutilisée, puis exploite le chemin qui retire de la file d’attente le signal spécialement conçu pour obtenir un shell root. La correction consiste à d2710c8d938a.

Les programmes échouent exec() toute la journée. Un chemin d'accès incorrect, un interpréteur manquant, un signal envoyé au mauvais moment. Aucun de ces éléments ne suffit toutefois à déclencher ces bogues. Le bogue lié au temporisateur nécessite que l'échec survienne après l'échange d'ID de thread, tandis que le bogue lié au signal nécessite qu'un attaquant remporte une course d'accès autour de ce même échange. Vu de l'extérieur, une tentative ressemble toujours à une activité normale des processus ; c'est pourquoi il n'existe aucun moyen simple de la filtrer, à moins d'appliquer un correctif.

La vulnérabilité CVE-2026-89754 se situe dans le « page table walker ». Lors d'une situation de concurrence avec madvise(MADV_DONTNEED), un indicateur de nouvelle tentative provenant d'un niveau inférieur se propage vers le haut, et mincore() parcourt deux fois la même plage. À ce moment-là, son curseur de sortie est déjà passé à autre chose, de sorte que le deuxième passage écrit au-delà d’un tampon temporaire d’exactement une page. L’exploit de Kim place un bloc d’identifiants dans la page physique suivante et utilise le débordement pour remettre à zéro les champs UID et GID d’un struct cred. En matière de LPE au niveau du noyau, on ne peut pas faire plus direct que ça. La solution consiste à aedf2efd1897.

La vulnérabilité CVE-2026-80775, dite « bug futex », nécessite que deux tâches partagent un mm_struct, qui s'imbriquait vfork() se produit dès que l’enfant du milieu est supprimé. Les deux s’empressent d’installer le premier compteur de références pour le hachage futex privé. Un seul enregistrement survit ; par conséquent, les références pointant vers l’autre compteur ne sont plus suivies, et un hachage encore en cours d’utilisation est libéré. L’exploit le récupère à l’aide d’un « pipe ring » et écrase le cache de pages de /usr/bin/passwd. Cela modifie ce que le noyau renvoie pour le fichier sans enregistrer la modification sur le disque ; ainsi, la falsification peut disparaître dès que la page mise en cache est effacée ou que l'ordinateur redémarre. Bonne chance pour enquêter là-dessus par la suite. La solution consiste à bde023808364.

Les deux dernières sont moins importantes pour la plupart des parcs informatiques. La vulnérabilité CVE-2026-98385 est une faille de type « use-after-free » dans le système de comptabilisation du cache du planificateur qui nécessite CONFIG_SCHED_CACHE=y dans la version, la comptabilisation du cache du planificateur est activée à l'exécution, et la topologie du processeur comporte plusieurs caches de dernier niveau. Son exploit a permis d'obtenir les privilèges root sur Arch Linux avec un noyau 7.2.4. CVE-2026-97941 est une condition de concurrence de type ABA lors du réapprovisionnement d’objets SLUB qui corrompt une liste partielle. Son déclencheur public provoque simplement une panique du noyau, et aucun exploit permettant d’obtenir les privilèges root n’a été publié à ce sujet. Ces deux vulnérabilités se trouvent dans du code apparu pour la première fois dans la version 7.2 ; par conséquent, aucun noyau de distribution pris en charge par KernelCare ne les contient.

Au moment de la rédaction de cet article, les notes NVD concernant les failles liées au timer et aux signaux n’avaient pas encore été attribuées. Amazon Linux a publié les notes pour trois d’entre elles, attribuant une note de 7,0 aux failles liées au timer et aux signaux avec le vecteur AV:L/AC:H/PR:L/UI:N/S:U/C:H/I:H/A:H, et 6.3 concernant le bug MM.

Le AC:H Cette partie mérite qu’on s’y attarde. La plupart de ces problèmes relèvent d’une « course à la sécurité », et « c’est une course » constituait autrefois une raison valable pour reléguer un problème en bas de la liste. Un exploit rendu public, qui a déjà fait le plus dur en remportant la course, change la donne. Une vulnérabilité de niveau 7.0 accompagnée d’un shell root fonctionnel, sur un hôte où des utilisateurs non fiables peuvent exécuter du code, mérite une place parmi les premières de la liste. Cela en dit plus long sur l’urgence que le chiffre lui-même.

Qui devrait s'inquiéter en premier ?

Chacun d'entre eux part d'un simple compte local, sans privilèges, sans espace de noms utilisateur et sans accès à des périphériques spécifiques. La vraie question est donc de savoir qui peut exécuter du code sur vos hôtes que vous ne contrôlez pas entièrement.

Les serveurs d’hébergement mutualisé dotés de shells SSH ou de panneaux de contrôle pour les clients constituent la réponse évidente. Les runners CI qui génèrent des pull requests arbitraires en sont une autre. Il en va de même pour tout hôte exécutant des conteneurs pour des locataires qui ne se font pas confiance. Kim classe ces cinq failles fondamentales comme des « évasions de conteneur », ce qui est tout à fait pertinent. Chaque conteneur partage le noyau de l’hôte, et les appels système impliqués sont des appels courants que les charges de travail des conteneurs utilisent en permanence. À moins qu’un profil seccomp ou une politique LSM ne bloque justement ce chemin d’accès, ne comptez pas sur la frontière du conteneur pour vous protéger.

Un serveur de base de données dédié, géré par trois administrateurs, c'est une autre histoire. Il a tout de même besoin de cette correction. Mais ce n'est tout simplement pas la priorité.

« Infinity Core » est-il une faille « zero day » ?

Non. Toutes les corrections ont été intégrées en amont avant que les failles ne soient rendues publiques, et la première entrée CVE remonte à environ six semaines avant la divulgation. Aucun cas d’exploitation en milieu réel n’a été signalé. Il s’agit ici de failles de type « n-days » pour lesquelles des exploits publics existent, ce qui peut placer les défenseurs dans une situation encore plus délicate. Le délai dépend désormais de la rapidité avec laquelle les distributions publient les noyaux corrigés et de la rapidité avec laquelle les administrateurs les installent effectivement.

Vulnérabilités des distributions prises en charge par KernelCare au 19 octobre 2026, d'après l'analyse réalisée par TuxCare et indépendamment de l'état du noyau de chaque éditeur :

L'expression « Crash so far » doit être nuancée. Un exploit permettant d'obtenir les droits root sur une version du noyau constitue un avantage considérable pour la version suivante, même si son adaptation nécessite encore un effort considérable. L'accès root n'a pas encore été démontré sur ces distributions, mais l'escalade locale des privilèges y constitue un risque réel, et la priorité accordée aux correctifs devrait en tenir compte.

Comme indiqué plus haut, une chaîne de version ne suffit pas à elle seule à trancher la question. Seuls un avis du fournisseur ou un correctif validé pour ce noyau précis permettent de trancher.

Procurez-vous KernelCare dès aujourd’hui →

Pourquoi il n'existe pas de solution rapide pour atténuer les effets

Pour bon nombre des LPE récentes du noyau, la solution provisoire tenait en une seule ligne de code : mettre un module sur liste noire, modifier un paramètre sysctl, désactiver les espaces de noms utilisateur non privilégiés. Rien de tout cela ne fonctionne cette fois-ci. Kim a délibérément omis les bogues qui nécessitent un espace de noms utilisateur, et les autres se trouvent dans exec(), traitement des signaux, mincore() et du code futex qu’aucun système en fonctionnement ne peut décharger ni désactiver. TuxCare n’a pas identifié de solution de contournement fiable. Les mesures habituelles, telles que la désactivation des espaces de noms utilisateur non privilégiés ou l’ajout d’un module à la liste noire, n’affectent pas les chemins de code vulnérables, et aucune solution de contournement spécifique n’a été vérifiée pour chaque bogue.

Il ne reste alors que les options moins satisfaisantes. Limiter l’accès au shell local sur les hôtes exposés jusqu’à ce qu’ils soient corrigés. Déplacer les locataires qui ne se font vraiment pas confiance vers des machines virtuelles distinctes plutôt que vers des conteneurs partageant un même noyau. Et surveiller le journal du noyau. Plusieurs de ces problèmes sont des situations de concurrence, et une tentative ratée peut provoquer un « oops » ou une « panic » du noyau plutôt qu’un échec silencieux, même si un journal vierge ne prouve pas qu’il ne s’est rien passé :

journalctl -k | grep -iE 'BUG:|Oops|general protection'

Un incident inexpliqué survenu cette semaine sur un serveur multi-utilisateurs mérite qu'on s'y attarde.

La solution définitive consiste à utiliser un noyau intégrant les correctifs en amont, qu'il provienne de votre distribution ou de votre propre compilation. L'installation du paquet n'affecte pas le noyau déjà en cours d'exécution en mémoire ; par conséquent, tant que l'hôte n'a pas redémarré avec le nouveau noyau, rien n'a changé. Vérifiez ce qui est réellement en cours d'exécution :

uname -r

Un serveur sur lequel un noyau corrigé a été installé, mais qui n'a jamais été redémarré, continue d'exécuter la version vulnérable. Les serveurs d'hébergement mutualisé et les pools d'infrastructure en continu (CI) sont généralement les plus touchés, car leur redémarrage implique d'avertir les clients ou d'interrompre les tâches en cours.

Une fois publiés pour votre noyau, les correctifs sans redémarrage de KernelCare appliquent la correction au noyau en cours d'exécution sans nécessiter de redémarrage. Lorsque les mises à jour automatiques sont activées, un correctif est récupéré lors de la prochaine vérification programmée dès qu'il est disponible dans le flux pour le noyau en cours d'exécution, et kcarectl --update le demande à la demande. Pour vérifier la prise en charge des quatre bogues affectant les noyaux des distributions prises en charge :

kcarectl --patch-info | grep -E 'CVE-2026-(98260|98256|89754|80775)'

Les CVE liées au planificateur et au SLUB sont délibérément exclues de ce schéma, car aucun noyau de distribution pris en charge ne les contient. Au 19 octobre 2026, le seul correctif Infinity Core publié est celui concernant les futex, destiné à une branche du noyau d’AlmaLinux 9. Aucun correctif n’a encore été fourni pour le bogue lié au timer sur aucune distribution, ni pour les quatre bogues sur Ubuntu 26.04. Consultez cet article pour connaître les mises à jour dans les prochains jours. Dès qu’un correctif est disponible pour votre branche, vérifiez que KernelCare l’a bien appliqué au noyau en cours d’exécution, et maintenez un accès restreint jusqu’à ce que la correction des CVE concernés soit vérifiée.

Pourquoi Infinity Core est-il si important ?

Le renforcement par soustraction a ses limites. Les administrateurs sont désormais très doués pour éliminer les surfaces d'attaque dont ils n'ont pas besoin, et ce travail porte ses fruits. Mais personne ne peut supprimer exec(). Kim est partie à la recherche de failles dans des sous-systèmes dont le bilan en matière de sécurité était plutôt calme et est revenue avec six failles. Un code mature et largement utilisé n’est pas nécessairement un code sûr, et le renforcement de la sécurité à lui seul ne suffit pas à combler cet écart.

Si vous utilisez Ubuntu 26.04 avec des utilisateurs locaux non fiables, c'est la première mise à jour à effectuer cette semaine. Sur les hôtes EL, Debian et Ubuntu 24.04, accordez une priorité absolue au bug du timer, même si les tests n’ont pour l’instant entraîné que des plantages, car l’exploit public d’Ubuntu fait de l’accès root une prochaine étape plausible. Et lorsqu’un redémarrage implique de vider un pool de CI ou d’envoyer un e-mail à plusieurs centaines de clients d’hébergement, les correctifs sans redémarrage de KernelCare sont conçus pour corriger ces bogues dans le noyau en cours d’exécution dès que la couverture est disponible, sans nécessiter de fenêtre de maintenance.

Procurez-vous KernelCare dès aujourd’hui →

Chronologie

Références

Le billet de Kim sur Infinity Core publié sur oss-security (16 octobre 2026), le dépôt InfinityCore contenant le code d’exploitation et les descriptions détaillées de chaque faille, les fiches CVE pour CVE-2026-98260, CVE-2026-98256, CVE-2026-89754, CVE-2026-80775, CVE-2026-98385 et CVE-2026-97941, l’ensemble complet des commits de correctifs en amont répertoriés dans le dépôt de Kim, y compris le correctif du timer acb03d388181 et le correctif du futex bde023808364, l’entrée du suivi de sécurité Debian pour CVE-2026-98260, le RHSA-2026:74438 de Red Hat, ainsi que les notes attribuées par Amazon Linux pour les CVE-2026-98260, CVE-2026-98256 et CVE-2026-89754.