DirtyDecrypt PoC augmente le risque d'escalade des privilèges dans le noyau près de la ligne principale

Un test de concept public qui profite d'une vulnérabilité corrigée récemment dans le module du noyau Linux rxgk augmente le risque pour les systèmes qui exécutent le noyau très près de l'arbre principal: l'explosion dite DirtyDecrypt (ou DirtyCBC) permet à un attaquant ayant un accès local de devenir racine dans certaines configurations système.

La racine technique du problème, selon les chercheurs qui ont publié le PoC, est l'écriture de pagecache causée par l'absence d'une vérification de copie à l'écriture (COW) sur la fonction rxgk _ decrypt _ skb: en termes simples, le code du noyau a fini par écrire où il ne devrait pas être sur des données partagées, qui ouvre la porte à l'escalade des privilèges. L'équipe V12 a publié le PoC et explique les détails dans son dépôt ( V12 PoC: DirtyDecrypt), et la description correspond à la correction enregistrée dans le NVD CVE-2026-31635.

Il est important de souligner deux facteurs qui ont un impact : premier, la tenue exige que le noyau soit compilé avec l'option CONFIG _ RXGK activée (c'est-à-dire prise en charge RxGK pour AFS / rxrpc); par conséquent, elle n'affecte que les distributions qui suivent de près le noyau en amont - par exemple Fedora, Arch ou OpenSUSE Tumbleweed - ou les systèmes avec noyau personnalisé y compris ce module. Deuxième, le vecteur est local: un attaquant doit exécuter du code sur la machine précédemment (par exemple à travers un compte utilisateur compromis ou un processus malveillant avec des capacités limitées) pour monter à racine.

L'existence d'un PdC public modifie le seuil de risque: avant qu'il ne soit corrigé en amont, tout adversaire ayant un accès local et des connaissances de base pourrait réutiliser le test pour prendre le contrôle complet du système si le patch n'est pas appliqué. Ce modèle n'est pas nouveau : au cours des dernières semaines, des défaillances de la même famille (Dirty Frag, Fragnesia, Copy Fail) et des organismes comme la CISA ont déjà mis en garde et énuméré les vulnérabilités exploitées dans le catalogue connu ( CISA Vulnérabilités exploitées connues), qui montre une vague d'exploitation active contre les vecteurs du noyau.

Ce que les administrateurs et les utilisateurs devraient faire: Mettre à jour le noyau pour les environnements de production où une mise à jour immédiate n'est pas pratique, appliquer une atténuation temporaire et contrôler l'accès local. Une atténuation précédemment utilisée contre des défaillances similaires est d'éviter le chargement des modules impliqués en créant une règle dans / etc / modprobe.d qui empêche leur installation, téléchargement des modules et vider des morceaux; être conscient que cette mesure peut briser IPsec et les systèmes de fichiers AFS distribués. Si vous l'adoptez, essayez-le d'abord dans des environnements contrôlés et comprenez l'impact sur la connectivité et les services.

En plus de la correction ou de l'atténuation, vérifiez la télémétrie et l'intégrité du système : recherchez des signes d'escalade des privilèges ou de persistance (sessions racine inattendues, nouvelles sessions binaires SUID, processus anormaux avec UID 0, changements dans / etc, entrées suspectes dans dmesg ou syslog). Si vous avez une détection de noyau ou EDR, vérifiez les événements liés à rxgk ou les opérations atypiques de pagecache; si vous n'avez pas ces outils, envisagez de déployer des contrôles qui limitent l'accès local et améliorent la segmentation des utilisateurs et des services.

Pour les équipements qui gèrent de grandes flottes, vous valorisez l'application de backports de sécurité offerts par la distribution, en utilisant des services Livepatch où ils sont disponibles et en priorisant la mise à jour du noyau dans des bastions ou des machines avec plusieurs comptes utilisateurs. Maintenir un processus d'intervention qui comprend l'isolement des hôtes suspects, la collecte de preuves et la restauration des sauvegardes connues propres au besoin.

La divulgation responsable et les preuves publiques nous rappellent également une leçon opérationnelle : les vulnérabilités dans l'espace du noyau, bien que locales, sont très précieuses pour les attaquants avec accès initial et accélérer le mouvement latéral et la persistance. Examiner les options de compilation du noyau sur les machines critiques (par exemple en consultant la configuration du noyau ou les paquets fournisseurs pour voir si CONFIG _ RXGK est actif) aide à prioriser les correctifs et les atténuations avec des critères techniques.

Si vous souhaitez approfondir les ressources techniques et les avis d'origine, consultez le PoC de l'équipe V12 à GitHub ( https: / / github.com / v12-security / pcs / arborescence / main / dirtydecrypt) et l'entrée NVD pour correction ( https: / / nvd.nist.gov / vuln / detail / CVE-2026-31635). Pour les politiques et la surveillance des défaillances exploitées dans l'écosystème, la base de la CISA est une référence utile ( https: / / www.cisa.gov / knowledge-exploited-vulnerabilities-catalog).

En bref : déjà stationner, réduire l'accès local non essentiel, surveiller les indicateurs d'engagement et préparer un plan d'intervention. La disponibilité publique du PA exige que, sans atténuation ni correction, la probabilité d'exploitation augmente rapidement.