Faille de sécurité - DirtyDecrypt

Au 20 mai 2026, DirtyDecrypt, aussi appelée DirtyCBC dans certains travaux de recherche, doit être traitée comme une alerte sérieuse pour les administrateurs Linux : un code de démonstration public décrit une escalade locale de privilèges dans le chemin RxGK/RxRPC du noyau. La prudence reste toutefois nécessaire sur l’étiquetage exact : la fiche officielle NVD CVE-2026-31635 décrit d’abord un défaut de vérification de longueur pouvant mener à un BUG_ON dans skb_to_sgvec(), tandis que les analyses DirtyDecrypt publiques documentent une primitive de corruption du cache de pages menant à root.

Ce qui est validé

Selon la fiche NVD, CVE-2026-31635 concerne le sous-système rxrpc du noyau Linux : rxgk_verify_response() accepte des authentificateurs RESPONSE trop grands à cause d’un contrôle inversé, puis les transmet à rxgk_decrypt_skb(), avec un passage possible vers skb_to_sgvec() et un plantage noyau. La fiche a été publiée le 24 avril 2026 et modifiée le 18 mai 2026, avec des références vers des correctifs stable.kernel.org.

Les recherches publiées par Delphos Labs le 15 mai 2026 vont plus loin sur DirtyCBC/DirtyDecrypt : elles décrivent un problème de déchiffrement en place avant vérification d’intégrité, sur des pages potentiellement partagées via MSG_SPLICE_PAGES. Le résultat démontré est un empoisonnement du cache de pages, suffisant pour obtenir un shell root depuis un utilisateur local non privilégié. Un PoC est également mentionné publiquement, notamment par The Hacker News et par le dépôt v12-security/pocs.

Impacts et systèmes à surveiller

DirtyDecrypt n’est pas une exécution de code à distance autonome : l’attaquant doit déjà disposer d’un accès local, d’un compte utilisateur ou d’un point d’entrée dans un conteneur. L’impact devient critique dans une chaîne d’attaque : élévation vers root, accès aux secrets locaux, contournement potentiel de l’isolation conteneur si le noyau hôte est vulnérable, et compromission de postes d’administration contenant clés SSH, profils cloud ou contextes Kubernetes.

Les environnements les plus exposés sont les noyaux récents ou rolling release avec RxGK/RxRPC activé. Les administrateurs doivent vérifier la configuration réelle avec grep RXGK /boot/config-$(uname -r) ou zcat /proc/config.gz | grep RXGK. Les conteneurs ne changent rien au risque : c’est le noyau de l’hôte qui compte.

Mitigation recommandée

• Appliquer immédiatement les mises à jour du noyau fournies par votre distribution, puis redémarrer.

• Vérifier que le noyau embarque les correctifs référencés par la NVD pour CVE-2026-31635 ou les correctifs ultérieurs du chemin RxRPC/RxGK.

• Si la mise à jour est impossible à court terme, désactiver temporairement