Une nouvelle vulnérabilité critique touchant le noyau Linux vient d’être révélée : DirtyDecrypt, référencée CVE-2026-31635. Découverte début mai 2026 par les équipes de sécurité Zellic et V12, elle permet à un attaquant disposant d’un simple accès local non privilégié d’obtenir les droits root complets sur un système vulnérable.
Une protection mémoire manquante dans le sous-système RxGK
Le problème se situe dans la fonction rxgk_decrypt_skb(), chargée du déchiffrement des paquets réseau entrants. Une protection copy-on-write (COW) — normalement chargée de créer une copie privée d’une page mémoire avant toute écriture partagée — est absente à cet endroit précis du code. Résultat : le noyau peut écrire directement dans des pages mémoire partagées avec d’autres processus, y compris dans le cache de fichiers sensibles comme le fichier des mots de passe système, celui des privilèges sudo ou des binaires SUID. Un attaquant local peut ainsi corrompre ces fichiers critiques pour s’octroyer les privilèges administrateur les plus élevés du système.
Quels systèmes sont concernés ?
DirtyDecrypt n’affecte que les distributions Linux compilées avec l’option CONFIG_RXGK activée, notamment Fedora, Arch Linux et openSUSE Tumbleweed. Les environnements conteneurisés ne sont pas épargnés : sur un nœud worker exécutant un noyau vulnérable, cette faille peut permettre à un conteneur compromis de s’évader de son pod et de compromettre la machine hôte. La vulnérabilité est classée avec un score CVSS de 7,5 (sévérité élevée).
Un correctif déjà disponible, mais un PoC désormais public
Un correctif avait été intégré discrètement dans le noyau principal avant même la publication du rapport de recherche — un scénario fréquent où un patch est mergé en amont sans communication immédiate sur la faille corrigée. Depuis, un code de preuve de concept (PoC) a été publié publiquement, ce qui change la donne : le risque d’exploitation dans la nature augmente fortement, y compris par des acteurs peu qualifiés capables de simplement réutiliser le code publié.
Que faire maintenant ?
Pour les administrateurs systèmes utilisant une distribution basée sur CONFIG_RXGK, la priorité est claire : vérifier immédiatement la version du noyau installée et appliquer le correctif disponible. À défaut de mise à jour immédiate possible, une désactivation temporaire du module RxGK — lorsque cela ne casse pas de dépendances applicatives — permet de réduire l’exposition en attendant un correctif planifié. DirtyDecrypt illustre une fois de plus une réalité récurrente en sécurité Linux : un mécanisme de protection mémoire fondamental, présent ailleurs dans le noyau, peut manquer sur un chemin de code spécifique — suffisant pour ouvrir une voie complète vers les privilèges root.