PinTheft : une vulnérabilité du noyau Linux permet une élévation de privilèges via RDS et io_uring

Où se situe la vulnérabilité dans le noyau Linux

La faille concerne le sous‑système RDS (Reliable Datagram Sockets), un protocole réseau utilisé principalement dans des environnements à haute performance, notamment les clusters InfiniBand et certaines infrastructures distribuées.

Le problème apparaît dans le chemin d’envoi zerocopy de RDS. Ce mécanisme vise à améliorer les performances en envoyant des données directement depuis la mémoire utilisateur vers le réseau sans copie intermédiaire.

La fonction clé, rds_message_zcopy_from_user(), épinglera (pin) les pages mémoire utilisateur une par une avant l’envoi. Si une erreur ou un page fault survient plus tard pendant l’opération, le code de nettoyage tente de libérer les pages déjà épinglées.

Dans certaines conditions, cette étape libère incorrectement des pages encore référencées, provoquant un double‑free ou une corruption du compteur de références.

Cette incohérence de gestion mémoire constitue la base de l’exploit PinTheft.

Comment fonctionne l’exploit PinTheft

Les chercheurs ont montré qu’en combinant ce bug avec certaines fonctionnalités modernes du noyau Linux, il est possible de transformer cette corruption mémoire en élévation de privilèges fiable.

1. Déclenchement du bug RDS zerocopy

L’attaquant local déclenche le chemin zerocopy vulnérable de RDS. Lorsqu’un défaut de page survient pendant l’épinglage des pages mémoire, la logique de nettoyage libère des pages qui devraient rester valides.

Résultat : le noyau se retrouve avec des pages libérées mais encore référencées ailleurs, créant un état mémoire incohérent.

2. Réutilisation des pages via les buffers fixes io_uring

L’exploit utilise ensuite io_uring, une interface moderne d’entrées‑sorties asynchrones introduite dans Linux pour améliorer les performances.

Avec la fonctionnalité fixed buffers, une application peut enregistrer des zones mémoire pour les opérations I/O. En manipulant ces buffers, l’attaquant peut réallouer les pages physiques précédemment libérées de manière contrôlée.

Cela lui donne une influence directe sur la mémoire impliquée dans la corruption.

3. Transformation en écrasement du page cache

Certaines de ces pages correspondent au page cache du noyau — la mémoire utilisée pour stocker temporairement les données des fichiers.

En contrôlant ces pages, l’attaquant peut transformer la corruption mémoire en primitive d’écriture dans le page cache.

Concrètement, cela signifie que le contenu d’un fichier servi par le noyau peut être modifié uniquement en mémoire, sans modifier le fichier sur disque.

4. Modification d’un binaire SUID‑root

La dernière étape consiste à cibler le cache mémoire d’un exécutable SUID-root.

Les fichiers SUID sont exécutés avec les privilèges de leur propriétaire (souvent root), même lorsqu’un utilisateur non privilégié les lance.

Si le contenu en cache du binaire est modifié, le noyau peut charger et exécuter du code altéré mais toujours avec les privilèges root.

L’attaquant obtient alors un accès root complet sur la machine.

Quels systèmes sont les plus exposés

La vulnérabilité existe dans les noyaux Linux contenant l’implémentation RDS zerocopy vulnérable, mais le risque dépend fortement de la configuration du système.

Arch Linux

Plusieurs analyses indiquent que Arch Linux a été l’environnement principal de démonstration :

• Un exploit PoC fonctionnel a été publié pour ce système.
• Le module RDS peut être disponible selon la configuration du noyau.

Cela en fait une cible privilégiée pour les tests et démonstrations de l’exploit.

Systèmes avec le module RDS actif

Toute distribution Linux peut être affectée si :

• le noyau vulnérable est installé ;
• le module RDS est disponible ou chargé.

Cependant, de nombreuses distributions d’entreprise ne chargent pas ce module par défaut.

Configurations serveur standards

Selon plusieurs analyses, les installations par défaut de Ubuntu, Debian, RHEL ou AlmaLinux sont généralement moins exposées, car le module RDS n’y est souvent pas activé par défaut. Cela doit néanmoins être vérifié au cas par cas.

Plateformes CloudLinux

CloudLinux a indiqué avoir testé l’exploit public sur plusieurs versions de sa plateforme et affirme que ses systèmes ne sont pas affectés.

Conditions nécessaires à l’exploitation

Pour réussir une attaque PinTheft, plusieurs conditions doivent généralement être réunies :

• l’attaquant doit disposer d’une exécution de code locale sans privilèges ;
• le système doit utiliser un noyau Linux vulnérable ;
• le module RDS doit être disponible ou chargeable ;
• io_uring doit être accessible aux utilisateurs non privilégiés ;
• un binaire SUID-root doit être présent pour servir de cible finale.

Sans cet ensemble de conditions, la chaîne d’exploitation devient beaucoup plus difficile, voire impossible.

Mesures de mitigation recommandées

Installer les correctifs du noyau

Les mainteneurs du noyau Linux ont publié un correctif pour le code RDS vulnérable. Installer la dernière version du noyau fournie par votre distribution est la mesure principale.

Un redémarrage du système est nécessaire pour appliquer la mise à jour du noyau.

Désactiver le module RDS si inutile

Si votre infrastructure n’utilise pas RDS, vous pouvez réduire la surface d’attaque en empêchant le chargement du module :

• blacklist du module rds
• suppression de son chargement automatique

Restreindre l’accès à io_uring

L’exploit s’appuie sur les fixed buffers io_uring. Restreindre ou désactiver l’accès à io_uring pour les utilisateurs non privilégiés peut réduire le risque dans certains environnements.

Auditer les binaires SUID

La phase finale de l’attaque cible les exécutables SUID. Réduire leur nombre et supprimer le bit SUID lorsqu’il n’est pas indispensable diminue les possibilités d’escalade.

Limiter l’accès local sur les systèmes partagés

Les machines multi‑utilisateurs — par exemple :

• serveurs d’hébergement partagé
• runners CI/CD
• serveurs de développement

— doivent être mises à jour en priorité, car la vulnérabilité nécessite un accès local.

Une tendance inquiétante dans les vulnérabilités du noyau

PinTheft illustre une tendance récente : les exploits modernes combinent plusieurs sous‑systèmes complexes du noyau pour transformer de petits bugs mémoire en attaques puissantes.

Dans ce cas précis, l’interaction entre RDS, le page cache et le framework io_uring permet de transformer une erreur de gestion mémoire en accès root complet.

La leçon reste la même pour les administrateurs système : maintenir les noyaux à jour, désactiver les modules inutiles et réduire la surface d’attaque restent les défenses les plus efficaces contre ce type de vulnérabilité.