Si vous utilisez le chiffrement intégral de disque avec LUKS et que votre machine part en veille, vous comptez sur une protection précise : l’effacement des clés de chiffrement depuis la RAM. Depuis le noyau Linux 6.9, cette protection ne fonctionne plus. C’est une régression silencieuse, sans annonce officielle, sans CVE publiée à ce jour.
LUKS suspend : à quoi sert le wipe des clés en mémoire ?
Le chiffrement de disque avec LUKS repose sur dm-crypt, le sous-système de chiffrement du noyau Linux. Quand le système tourne, les clés de déchiffrement sont chargées en mémoire vive. C’est inévitable : le noyau en a besoin pour lire et écrire les données chiffrées à la volée.
Le problème survient au moment de la mise en veille. Une machine en veille conserve le contenu de sa RAM. Un attaquant ayant un accès physique à cette machine peut réaliser une attaque dite cold boot : en refroidissant les barrettes mémoire ou en les transférant rapidement vers un autre système, il peut extraire leur contenu, clés de chiffrement comprises.
La fonction LUKS suspend existait précisément pour contrer ce scénario. Avant la mise en veille, elle effaçait les clés de la RAM. Au réveil, le système demandait la phrase de passe pour les recharger. C’est un compromis confort contre sécurité, mais c’est un choix documenté et délibéré que les utilisateurs pouvaient faire.
La régression introduite depuis Linux 6.9
Depuis la version 6.9 du noyau, ce wipe ne se produit plus. Les clés de chiffrement restent en mémoire pendant et après la mise en veille. Le comportement attendu de LUKS suspend n’est plus respecté.
Le signal d’alarme a été lancé le 18 juin 2026 par Ingo Blechschmidt, sur le réseau social Mathstodon. La communauté Privacy Guides a relayé le sujet le 2 juillet 2026. Ce sont des canaux techniques et orientés vie privée, pas les listes de diffusion du noyau.
C’est là que le problème devient préoccupant. Aucune discussion visible sur la LKML, aucun commit correctif identifié, aucune CVE assignée, aucune réponse publique des mainteneurs du sous-système dm-crypt. La régression semble être passée sous le radar des canaux officiels.
Ce que ça change concrètement pour les utilisateurs
Si vous êtes sur un noyau 6.9 ou supérieur et que vous utilisez LUKS avec mise en veille, voici la situation réelle :
- Vos clés de chiffrement restent en RAM pendant la veille.
- Un accès physique à votre machine en veille expose potentiellement ces clés.
- La protection contre les attaques cold boot que vous pensiez avoir n’est plus active.
- Aucun correctif officiel ni contournement documenté n’a été annoncé à ce stade.
Les distributions concernées sont toutes celles qui tournent sur un noyau 6.9 ou plus récent : les versions récentes d’Arch Linux, Fedora, et potentiellement Debian testing ou Ubuntu avec HWE kernel sont dans le périmètre. Les configurations de veille exactes concernées (suspend-to-RAM, suspend-to-disk) restent à préciser dans un rapport de bug formel.
Ce qui manque encore pour évaluer la criticité réelle
Les informations disponibles restent parcellaires. Plusieurs points essentiels ne sont pas encore documentés publiquement :
Le commit précis responsable du changement de comportement depuis Linux 6.9 n’a pas été identifié dans les sources disponibles. Sans ce commit, il est difficile de savoir si c’est une régression involontaire ou un changement d’architecture délibéré mal documenté.
Aucun rapport de bug n’a été ouvert publiquement sur le bugzilla du noyau ou le dépôt cryptsetup, du moins dans la fenêtre d’observation disponible. C’est anormal pour une régression de cette nature.
Enfin, aucune évaluation d’impact par les grandes distributions n’a été publiée. Debian, Fedora et Arch ont des équipes de sécurité réactives : leur silence relatif peut indiquer que le problème n’a pas encore atteint ces canaux, pas qu’il est sans importance.
Que faire en attendant un correctif ?
En l’absence de patch confirmé, la posture raisonnable est de traiter ce risque comme non mitigé sur les noyaux 6.9 et supérieurs. Quelques options pratiques :
- Préférer l’hibernation (suspend-to-disk) avec chiffrement de la partition de swap, qui évite de laisser la machine dans un état de veille RAM prolongé.
- Éteindre complètement la machine plutôt que de la mettre en veille dans les contextes à risque (déplacement, accès physique non contrôlé).
- Surveiller le dépôt cryptsetup et les annonces de sécurité de votre distribution pour l’apparition d’un correctif.
- Consulter la LKML et le bugzilla du noyau pour suivre l’évolution du signalement officiel.
Ce n’est pas une solution, c’est une réduction d’exposition en attendant mieux.
Ce qu’il faut retenir
- Depuis Linux 6.9, LUKS suspend ne wipe plus les clés de chiffrement de la RAM lors de la mise en veille, ce qui annule la protection contre les attaques cold boot.
- La régression a été signalée publiquement en juin 2026 par Ingo Blechschmidt, sans réponse officielle des mainteneurs visible à ce jour.
- Aucune CVE, aucun patch, aucun rapport de bug officiel n’a été publié dans la fenêtre d’observation disponible.
- Les utilisateurs de LUKS avec mise en veille sur noyau 6.9 et supérieur doivent considérer ce risque comme actif et non mitigé.
- La priorité est de surveiller cryptsetup, la LKML et les bulletins de sécurité des distributions majeures.
Si vous gérez des postes Linux avec chiffrement LUKS en environnement professionnel, ce point mérite une attention immédiate. N’hésitez pas à me contacter ou à suivre le blog pour les mises à jour sur ce sujet.
Sources
- Privacy Guides Community, discussion du 2 juillet 2026 : https://discuss.privacyguides.net/t/since-linux-6-9-luks-suspend-stopped-wiping-disk-encryption-keys-from-memory/38949
- Publication originale de Ingo Blechschmidt sur Mathstodon (@iblech@mathstodon.xyz), 18 juin 2026
- Dépôt cryptsetup (référence pour suivre un éventuel correctif) : https://gitlab.com/cryptsetup/cryptsetup