Une nouvelle faille du noyau (CVE-2026-43494, « PinTheft ») permet d'obtenir des privilèges root en local lorsque RDS et io_uring sont exposés

En bref

De quoi s'agit-il ? D'une nouvelle faille de sécurité sous Linux permettant l'escalade de privilèges en local, baptisée « PinTheft ». Elle exploite en chaîne une faille de comptage de références dans le chemin d'envoi « zerocopy » du protocole RDS (Reliable Datagram Sockets) du noyau, en combinaison avec la fonction io_uring, afin de réécrire un binaire SUID root en mémoire. Il en résulte l'obtention d'un shell root à partir d'un compte local sans privilèges. Aucun identifiant CVE n'avait encore été attribué au moment de la publication.

Impact : une démonstration publique de faisabilité réalisée par V12 Security permet à n'importe quel utilisateur local sans privilèges d'accéder de manière fiable aux droits root sur les hôtes concernés. La faille sous-jacente est présente dans le noyau Linux depuis la version 4.17, publiée en 2018.

Situation : Aaron Esau, de V12 Security, la société à l'origine de cette découverte, a révélé PinTheft en mai, avec un correctif du noyau déjà disponible. Le correction en amont a été publiée sur la liste de diffusion netdev du noyau le 5 mai 2026. Le numéro CVE-2026-43494 a été attribué, sans score CVSS. Voir la section « Patch sans redémarrage de KernelCare » ci-dessous pour connaître l'état actuel.

Gravité : vecteur local ; nécessite la possibilité d'exécuter du code sur l'hôte en tant que n'importe quel utilisateur local ; aucune interaction de l'utilisateur. L'exploitabilité pratique nécessite que tous les éléments suivants soient présents sur la cible : RDS et RDS_TCP disponibles et chargeables, io_uring activé, un binaire SUID-root lisible et une charge utile x86_64 (le PoC est spécifique à l'architecture même si la technique ne l'est pas). V12 a indiqué que, parmi les distributions courantes qu'ils ont testées, RDS n'était chargeable par défaut que sur Arch Linux. D'autres distributions fournissent le module avec le chargement automatique désactivé ou ne le compilent pas du tout.

Pourquoi est-ce important ? La chaîne d'exploitation est fiable, la preuve de concept est publique, et il n'existe pour l'instant ni CVE ni avis officiel des éditeurs. Les systèmes Linux multi-locataires (hébergement mutualisé, environnements d'intégration continue, hôtes de conteneurs) fonctionnant sous les distributions concernées doivent être considérés comme exposés à un risque immédiat.

Procédez ainsi dès maintenant: si votre hôte n'exécute pas de charge de travail RDS – ce qui est le cas de la plupart d'entre eux –, bloquez les modules rds et rds_tcp à l'aide d'une règle modprobe. Si io_uring n'est pas nécessaire et que votre noyau est en version 6.6 ou plus récente, vous pouvez en outre le désactiver à l'aide d'une seule commande sysctl. Vous trouverez ci-dessous les commandes de mitigation ainsi que la solution de secours pour les noyaux plus anciens.

La version longue

V12 Security a publié en mai 2026 une démonstration de faisabilité (proof of concept) et un rapport technique concernant PinTheft. La découverte est attribuée à Aaron Esau. La faille elle-même est présente dans le noyau Linux depuis la version 4.17 de 2018, mais la chaîne d'exploitation repose sur des fonctionnalités io_uring qui n'existaient pas lorsque le bogue a été introduit.

Le correctif proposé pour le noyau a été diffusé sur la liste de diffusion netdev le 5 mai 2026. Les noyaux des distributions en aval continuent de l'intégrer. L'équipe d'ingénierie de KernelCare prépare actuellement des correctifs sans redémarrage pour les noyaux pris en charge concernés.

Certaines des premières analyses ont spécifiquement associé PinTheft au noyau 6.13 et aux versions ultérieures. Cela reflète les dépendances du PoC publié, et non la durée de vie de la faille sous-jacente : le problème de comptage de références dans le chemin zerocopy de RDS est bien plus ancien, mais une chaîne d'exploitation fonctionnelle calquée sur le PoC nécessite tout de même les fonctionnalités récentes d'io_uring.

Comment fonctionne cette faille

Lorsqu'un programme envoie des données via un socket réseau, le noyau copie généralement ces données depuis la mémoire du programme vers des tampons du noyau. Afin d'économiser des cycles CPU, les noyaux modernes proposent également l'envoi « zerocopy » : le noyau verrouille les pages mémoire de l'utilisateur et les utilise directement. Le protocole RDS, un protocole moins courant destiné aux réseaux de centres de données haute performance, prend en charge ce mode zerocopy.

Le problème réside dans la manière dont RDS gère la situation lorsqu'un envoi en mode « zerocopy » échoue en cours de route. Le noyau finit par libérer deux fois les mêmes pages au lieu d'une seule. Chaque envoi ayant échoué « vole » une référence à la première page utilisateur.

En soi, il ne s'agit que d'un petit bug de gestion interne. PinTheft le transforme en une faille permettant d'obtenir les privilèges root via io_uring, l'interface moderne d'E/S asynchrone de Linux. io_uring permet à un programme d'enregistrer une page mémoire en tant que tampon fixe, ce qui ajoute 1 024 références à cette page. L'attaquant force ensuite 1 024 opérations RDS zerocopy vouées à l'échec afin d'épuiser silencieusement toutes ces références. Le noyau pense alors que personne n'utilise la page et la libère, mais io_uring conserve toujours un pointeur vers celle-ci.

Ensuite, l'attaquant lit n'importe quel binaire SUID root. Le noyau charge ce binaire dans la même page libérée de son cache de pages. Une simple écriture io_uring dans le tampon périmé écrase le binaire en mémoire avec du shellcode. L'exécution du binaire SUID permet alors à l'utilisateur d'accéder à un shell root.

Le fichier sur le disque reste inchangé. C'est la copie du cache de pages en mémoire qui est écrasée. Cela a une incidence sur le nettoyage, comme expliqué dans la section consacrée aux mesures d'atténuation.

Ce bogue latent lié au compteur de références semble remonter à l'introduction de la prise en charge de RDS zerocopy dans Linux 4.x. Une exploitation fiable, comme le montre le PoC, dépend en outre de fonctionnalités io_uring plus récentes (notamment IORING_REGISTER_CLONE_BUFFERS, disponible à partir de la version 6.12) ; ainsi, bien que le bogue soit ancien, la fenêtre d'exploitation pratique est plus restreinte.

Qui est concerné ?

Ce qui importe avant tout, c'est de savoir si le noyau en cours d'exécution peut charger les modules RDS, et non le nom de la distribution. Vérifiez directement la configuration du noyau et la politique de chargement des modules à l'aide des commandes présentées dans la section suivante.

Système d'exploitation RDS pouvant être chargé par défaut (confirmé par les chercheurs) : Arch Linux.

Le module RDS est fourni mais son chargement automatique est bloqué par défaut : Ubuntu (toutes les versions actuellement prises en charge, via un fichier de liste noire dans le paquet kmod), Debian 11 et 12 (via un correctif spécifique à Debian qui désactive le chargement automatique de RDS afin de limiter les exploits locaux), Fedora (CONFIG_RDS=m, mais le module est fourni dans kernel-modules-extra et inclut son propre fichier de liste noire). Sur ces systèmes, le PoC nécessite qu'un administrateur ou une charge de travail charge délibérément rds_tcp en premier. Des tests indépendants indiquent également que le chargement du module sur un système standard dérivé de Debian n'est pas toujours suffisant pour que le PoC aboutisse, le comportement pouvant donc varier.

Nécessite une vérification spécifique au fournisseur ou à la configuration : Amazon Linux 2023, openSUSE Tumbleweed, Proxmox VE 7/8/9, Oracle Linux UEK 6 et 7. Vérifiez le fichier CONFIG_RDS dans /boot/config-$(uname -r) et recherchez les règles modprobe fournies par le fournisseur dans les répertoires /etc/modprobe.d/ et /lib/modprobe.d/.

Non concernés : RHEL, AlmaLinux, Rocky Linux et CentOS Stream 8/9/10 exécutant le noyau compatible Red Hat par défaut — ces versions n'incluent pas RDS. RHEL 9 et 10 désactivent également io_uring par défaut, supprimant ainsi l'autre maillon de la chaîne.

Une mise en garde qui prime sur tout ce qui précède : tout hôte exécutant un noyau personnalisé ou alternatif peut se comporter différemment de sa distribution d'origine. Oracle Linux UEK, en particulier, fonctionne souvent en parallèle avec le RHCK et se trouve dans une situation différente.

Agir dès maintenant

Il existe deux solutions pratiques. Choisissez en fonction du fait que votre hébergeur utilise RDS ou io_uring.

Recommandé pour la plupart des serveurs : bloquer les modules RDS

La grande majorité des serveurs Linux n'utilisent pas RDS. On le trouve principalement dans les clusters Oracle et dans certaines configurations HPC InfiniBand. Sur tout hôte qui n'exécute pas de charge de travail RDS, la solution la plus simple consiste à empêcher le chargement des modules rds et rds_tcp.

sudo sh -c "printf 'install rds /bin/false\ninstall rds_tcp /bin/false\n' > /etc/modprobe.d/pintheft.conf"
sudo rmmod rds_tcp rds 2>/dev/null || true

Cette faille ne modifie que le fichier binaire SUID en mémoire. Le fichier sur le disque reste inchangé. Sur tout hôte susceptible d'avoir été ciblé avant la mise en place des mesures correctives, videz le cache de page afin d'effacer toute modification effectuée en mémoire :

sudo sh -c 'echo 3 > /proc/sys/vm/drop_caches'

Revenir à la version d'origine après l'application du correctif du noyau ou du correctif en direct KernelCare :

sudo rm /etc/modprobe.d/pintheft.conf

Si vous exécutez des charges de travail RDS ( Oracle Clusterware, certaines piles HPC), n'appliquez pas cette mesure corrective. Utilisez la solution de rechange io_uring ci-dessous ou attendez la sortie du noyau corrigé.

Autre solution : désactiver io_uring à l'échelle du système

Le paramètre sysctl « kernel.io_uring_disabled » est disponible sous Linux 6.6 et versions ultérieures. Les noyaux de distribution antérieurs à cette version — notamment Ubuntu 22.04 (5.15), Debian 11 (5.10) et 12 (6.1), Amazon Linux 2023 (6.1), RHEL 9 (5.14) et Ubuntu 24.04 (6.8 — vérifiez votre version mineure) — ne prennent pas en charge ce paramètre sysctl.

Sur ces noyaux, bloquer les modules RDS est la solution la plus pratique. Désactiver complètement io_uring sur les anciens noyaux nécessite un paramètre de démarrage ou une recompilation du noyau, et cela n'en vaut généralement pas la peine par rapport au blocage de RDS.

Si vos charges de travail ne nécessitent pas io_uring, désactivez plutôt l'autre moitié de la chaîne d'exploitation.

sudo sysctl -w kernel.io_uring_disabled=2

Il s'agit du paramètre par défaut sous RHEL 10, ce qui explique pourquoi cette famille de distributions reste exclue du champ d'application, quel que soit l'état du RDS. Notez que la désactivation de io_uring peut avoir des répercussions sur certains moteurs de base de données modernes et sur les charges de travail en E/S asynchrones. Testez cette modification dans votre environnement avant de l'appliquer.

Conserver les paramètres après les redémarrages :

echo 'kernel.io_uring_disabled = 2' | sudo tee /etc/sysctl.d/99-pintheft.conf
sudo sysctl --system

Défense en profondeur sur des hôtes renforcés

Si votre charge de travail ne charge pas les modules du noyau au moment de l'exécution, définir kernel.modules_disabled=1 après le démarrage empêche tout appel ultérieur à modprobe de aboutir, ce qui désactive d'un seul coup le chargement automatique de RDS et de tous les autres modules.

Cette approche est plus restrictive que le simple ajout de RDS à la liste noire et ne doit être utilisée que dans les cas où aucun chargement de module n'est prévu en cours d'exécution (pas de matériel à connexion à chaud, pas de modules de système de fichiers ou de réseau à la demande, pas d'environnements d'exécution de conteneurs chargeant des modules lors de la première utilisation).

sudo sysctl -w kernel.modules_disabled=1

Veuillez noter que ce paramètre est un commutateur à sens unique au cours d'un démarrage : il ne peut pas être réinitialisé à 0 sans redémarrer. Testez-le dans un environnement hors production avant de le déployer.

Vérifiez si votre serveur est exposé

Effectuez les trois vérifications ci-dessous et comparez les résultats aux critères indiqués à la fin de cette section.

1. Le RDS est-il disponible dans la version du noyau ?

   grep -E 'CONFIG_(RDS|RDS_TCP|IO_URING)' /boot/config-$(uname -r)
   modprobe -n -v rds_tcp
   ls /lib/modules/$(uname -r)/kernel/net/rds/ 2>/dev/null

2. La fonction io_uring est-elle activée ?

   cat /proc/sys/kernel/io_uring_disabled

3. Ces modules figurent-ils déjà sur la liste noire ?

   grep -rEn '^\s*(blacklist|install)\s+rds' /etc/modprobe.d/ /etc/modules-load.d/ 2>/dev/null

Un hôte ne constitue une cible valable que si toutes les conditions suivantes sont remplies : CONFIG_RDS et CONFIG_RDS_TCP sont disponibles, io_uring_disabled vaut 0, et les modules rds et rds_tcp ne figurent pas sur la liste noire.

Correctif sans redémarrage KernelCare

Cette section est mise à jour au fur et à mesure que les correctifs sont intégrés. Vérifiez la date indiquée sur la ligne de mise à jour en haut de l'article.

Situation au 21 mai 2026, 12 h UTC : les correctifs KernelCare pour toutes les distributions (à l'exception de Debian 12 et Proxmox 8) ont été intégrés au flux principal.

Une fois disponible dans le flux de test :

kcarectl --update --prefix test

Une fois validé, le correctif est déployé lors de la prochaine exécution planifiée, ou vous pouvez le récupérer à la demande :

kcarectl --update

Vérifiez que le correctif a bien été appliqué. Une fois qu'un numéro CVE a été attribué, vérifiez à l'aide de :

kcarectl --patch-info | grep CVE-XXXX-XXXXX   # à remplacer par le numéro CVE

À surveiller au fur et à mesure que la situation évolue

• Attribution de numéros CVE (aucun au moment de la rédaction)
• Un avis officiel émanant de V12 Security ou de l'équipe de sécurité du noyau
• Mises à jour du noyau provenant d'Ubuntu, de Debian, d'Amazon Linux, d'openSUSE, d'Oracle et de Proxmox
• Publication du correctif KernelCare pour toutes les versions de noyau prises en charge

Cet article sera mis à jour dès qu'un numéro CVE aura été attribué et que les correctifs KernelCare passeront de la phase de test à la version stable. Les clients KernelCare recevront automatiquement le correctif dès qu'il sera intégré au flux principal.

Appliquez les correctifs à tous les noyaux, sans redémarrage

Si vous n'utilisez pas encore KernelCare, c'est le moment idéal pour découvrir comment les correctifs sans redémarrage peuvent protéger vos systèmes Linux critiques sans nécessiter de fenêtres de maintenance d'urgence ni de temps d'arrêt.

Pour en savoir plus sur KernelCare, cliquez ici →