Le 18 juin 2026, un mathématicien du nom d’Ingo Blechschmidt a publié un fil de discussion sur Mastodon qui commençait par ces mots : « Ces derniers jours, j’ai été plongé dans un voyage de débogage fascinant, profondément gratifiant, mais aussi terriblement terrifiant. » Il révélait ensuite un fait stupéfiant : depuis la sortie du noyau Linux 6.9 en mai 2024, soit pendant plus de deux années entières, la clé de déchiffrement de son disque dur chiffré restait en mémoire sans être effacée après qu’il ait refermé le capot de son ordinateur portable.
En d’autres termes, son chiffrement complet de disque ne servait à rien.
Quelques jours plus tard, le fil est apparu sur Hacker News où il a rapidement atteint 379 points et 182 commentaires. Après avoir lu l’intégralité de la discussion et les commits associés dans le dépôt du noyau, l’auteur de ces lignes a réalisé que cette affaire est bien plus nuancée qu’il n’y paraît — ce n’est pas une faille de sécurité spectaculaire, mais c’est précisément parce que ce n’en est « pas vraiment une » qu’elle devient si instructive.
Figure : le chiffrement complet de disque sous Linux (LUKS) repose sur une clé stockée en mémoire pour déchiffrer les données du disque. Si la clé n’est pas effacée, un attaquant disposant d’un accès physique peut l’extraire. Source : hacknjill.com
Commençons par une analogie : le code de votre valise
Pour comprendre cette affaire, pas besoin de savoir programmer. Prenons une analogie de la vie quotidienne.
Imaginez que vous possédez une valise à code. Tout ce qu’elle contient est chiffré : si quelqu’un met la main sur votre valise sans connaître le code, il ne peut pas l’ouvrir. Ce code (en informatique, on l’appelle « clé de chiffrement ») est normalement conservé dans votre cerveau (en informatique, dans la « mémoire vive »).
Chaque fois que vous fermez votre valise (l’équivalent de « fermer le capot de l’ordinateur portable »), la première chose que vous devriez faire est d’effacer le code de votre cerveau, de sorte que même si quelqu’un vole votre valise pendant votre absence, il ne puisse pas l’ouvrir. À votre retour, vous ressaisissez le code.
C’est exactement ce que la fonction luksSuspend du standard de chiffrement complet LUKS est censée accomplir : avant que l’ordinateur portable n’entre en veille, elle efface la clé de déchiffrement de la mémoire vive. Au réveil, le système vous demande de ressaisir votre mot de passe, la clé est rechargée, et le disque redevient accessible.
Cette logique est élégante — et cruciale. Car lorsque vous refermez le capot d’un ordinateur portable, celui-ci n’est pas éteint : la mémoire vive est toujours alimentée, les données y résident encore. Si la clé n’a pas été effacée, une personne mal intentionnée qui s’empare physiquement de votre machine (en la maintenant sous tension) peut, par une « attaque par démarrage à froid » — congeler les puces mémoire pour les lire, ou accéder directement à la mémoire via les interfaces Thunderbolt/USB —, dérober votre clé de chiffrement.
Et ce qu’Ingo Blechschmidt a découvert, c’est que depuis mai 2024, l’action d’effacement de luksSuspend a silencieusement cessé de fonctionner.
Figure : la clé de chiffrement est stockée dans les puces de mémoire vive (RAM). Si le système ne l’efface pas avant la mise en veille, un attaquant peut l’extraire par des moyens physiques. Source : sesamedisk.com
Comment une refonte « raisonnable » du noyau a-t-elle ouvert une brèche de sécurité ?
Ingo a utilisé git bisect — un outil qui permet de localiser de manière semi-automatique l’origine d’un problème dans l’historique des versions du code. Il a remonté jusqu’au commit fautif : a28d893eb327, intitulé « md: port block device access to file », que l’on pourrait traduire par « porter l’accès aux périphériques bloc vers le modèle fichier ».
Ce commit n’avait rien de malveillant, et ce n’était pas une erreur de débutant. C’était une refactorisation légitime et utile menée par les développeurs du noyau Linux — elle consistait à migrer la manière dont le noyau gère les lectures et écritures sur disque d’une ancienne interface vers une nouvelle. Un peu comme si vous remplaciez les vieux câbles électriques en aluminium de votre maison par du cuivre : la logique est « plus propre, plus moderne ».
Le problème, c’est que cette refonte a modifié un mécanisme de bas niveau apparemment sans rapport : la gestion du cycle de vie du trousseau de clés de thread (thread keyring).
Il faut ici expliquer ce qu’est un « trousseau de clés ». Dans le noyau Linux, les clés de chiffrement ne sont pas simplement abandonnées dans un coin de la mémoire. Elles sont stockées dans une structure de données dédiée appelée « trousseau de clés » (keyring). Le trousseau de clés de thread est un trousseau particulier : il est lié à un thread (un fil d’exécution) du programme. Lorsque le thread se termine, le trousseau doit être détruit, et les clés qu’il contient disparaissent avec lui.
La conception de luksSuspend repose précisément sur cette propriété : elle téléverse la clé de chiffrement du disque dans un trousseau de clés de thread temporaire, et lorsque ce thread se termine, le trousseau est automatiquement détruit, et la clé s’évanouit.
La documentation du noyau est parfaitement claire à ce sujet : c’est une garantie officielle. Mais la refonte introduite dans la version 6.9 a, par un enchaînement de circonstances malheureuses, fait que le trousseau de clés de thread n’était plus détruit dans certaines situations. Le thread se terminait, mais le trousseau restait accroché en mémoire comme un fantôme — avec, à l’intérieur, la clé de déchiffrement du disque.
Le plus ironique, c’est que la correction de cette vulnérabilité tient en une seule ligne de code.
Oui, une ligne. Après avoir découvert la faille, Ingo a soumis un correctif à la liste de diffusion du noyau. La modification est minuscule : il s’agit d’ajouter un appel de nettoyage à une structure de données. Pour les curieux, la logique est la suivante : ajouter un key_put(key) dans une fonction du noyau, pour garantir que la référence à la clé qui n’est plus utilisée soit correctement libérée.
Mais Ingo lui-même reconnaît dans son fil de discussion : « Sans preuve formelle, je ne peux pas affirmer que mon patch est correct, ni être certain qu’il ne provoquera pas ses propres interactions à longue portée… » Voilà les mots d’un véritable ingénieur.
Sans l’infrastructure de test de NixOS, cette vulnérabilité n’aurait peut-être jamais été découverte
Il y a un autre protagoniste clé dans cette histoire : NixOS.
Si vous ne connaissez pas NixOS, disons simplement que c’est une distribution Linux « reproductible » : la configuration complète du système tient dans un seul fichier, que l’on peut gérer avec Git, et que l’on peut copier-coller sur une autre machine pour reconstruire un système rigoureusement identique. La communauté NixOS est réputée dans le monde Linux pour son investissement dans les tests automatisés.
Le découvreur, Ingo, est lui-même issu de cette communauté. La première chose qu’il a faite après avoir identifié la faille a été de soumettre un test d’intégration automatisé au dépôt de code de NixOS (PR #532499). Ce test sera exécuté automatiquement à chaque mise à jour du noyau : il simule un disque chiffré avec LUKS → exécute luksSuspend → vérifie s’il reste des résidus de clé en mémoire.
En d’autres termes, tout en réparant sa propre machine, il s’est assuré que cette vulnérabilité ne reviendrait jamais.
Et ce n’est pas tout. Ingo a également soumis un autre correctif au projet cryptsetup (MR #936), pour que la commande luksSuspend ne soit plus un « échec silencieux » : pendant deux ans, elle n’effaçait pas la clé sans émettre la moindre erreur ; désormais, si l’effacement échoue, elle émettra un avertissement explicite.
Ces deux gestes reflètent une véritable philosophie d’ingénierie : quand tu trouves un problème, ajoute un test pour éviter qu’il ne revienne ; quand tu trouves un échec silencieux, rends-le bruyant. C’est ce qui incarne la bonne pratique d’ingénierie, bien plus que n’importe quelle prouesse technique.
Quel est le périmètre d’impact : qui doit s’inquiéter ?
À ce stade, le lecteur pourrait se demander : j’utilise Windows ou Mac, ça ne me concerne pas, non ? J’ai un portable Linux, dois-je l’éteindre immédiatement ?
La réponse est nuancée.
Premièrement, cette vulnérabilité ne concerne que les utilisateurs de distributions de la famille Debian (Debian, Ubuntu, Linux Mint, etc.) qui ont installé le paquet cryptsetup-suspend. En effet, la fonction luksSuspend elle-même est une extension développée par la communauté Debian : elle ne fait pas partie du comportement par défaut de Linux upstream. Beaucoup d’autres distributions (comme l’installation par défaut d’Arch Linux ou de Fedora) n’ont tout simplement pas cette fonction — chez elles, la clé de chiffrement reste en mémoire pendant toute la durée de la veille. Ce n’est pas une vulnérabilité, c’est un choix de conception.
Deuxièmement, même si vous êtes concerné, la vulnérabilité n’existe que dans le scénario « fermer le capot pour mettre en veille ». Si vous éteignez normalement votre machine à chaque fois (plutôt que de simplement fermer le capot), la clé est correctement effacée lors de l’extinction. Le problème ne se manifeste qu’en mode veille (suspend).
Troisièmement, l’attaque exige un accès physique. Un pirate distant ne peut pas voler votre clé de chiffrement à travers le réseau. Il faut qu’une personne réelle mette la main sur votre ordinateur encore allumé, puis procède à une attaque par démarrage à froid, une attaque DMA ou un autre moyen physique d’extraction. Pour le citoyen ordinaire, la menace est faible — la personne qui vole votre ordinateur veut probablement juste le revendre, pas faire de la forensique mémoire. Mais pour les avocats, les journalistes, les dissidents, les voyageurs d’affaires transfrontaliers — tous ces « profils à haut risque » —, l’attaque physique est une menace bien réelle.
Ingo a d’ailleurs pris soin de clarifier dans sa réponse sur HN : « Cela n’affecte pas les utilisateurs qui utilisent une configuration standard, pour la simple raison qu’ils ne s’attendaient de toute façon pas à ce que leur clé soit en sécurité pendant la veille. » Mais toute la raison d’être de cette fonction était précisément de protéger la clé pendant le sommeil de la machine. Pendant deux ans, ceux qui ont fait confiance à ce mécanisme ont été trahis.
Une leçon plus profonde : le risque des correctifs spécifiques aux distributions
Cette vulnérabilité a en réalité deux « méchants ».
Le premier méchant, c’est la refonte du noyau — une réorganisation du code bien intentionnée qui a ouvert une brèche de sécurité faute de compréhension exhaustive de toutes ses implications. C’est presque une tragédie classique du génie logiciel : le code n’est pas « mauvais », il est simplement trop complexe pour que quiconque puisse en voir toutes les réactions en chaîne.
Le second méchant est plus intéressant : le risque de maintenance lié aux correctifs appliqués par les distributions elles-mêmes.
luksSuspend est une fonction écrite par la communauté Debian, pas par l’équipe upstream du noyau Linux. Cela signifie que sa correction n’est pas de la responsabilité de Linus Torvalds et de ses mainteneurs. Lorsqu’un mécanisme de bas niveau du noyau upstream change (comme le comportement du trousseau de clés de thread dans la version 6.9), est-ce que le patch Debian a été adapté en conséquence ? Personne ne peut le garantir. Parce que les développeurs upstream ignorent tout simplement l’existence de ce patch.
Cela ne veut pas dire que les distributions ne devraient pas appliquer leurs propres correctifs. Bien au contraire, de nombreuses fonctionnalités excellentes des distributions Linux ont commencé comme des « patches maison ». Mais cette affaire nous rappelle une réalité facile à oublier : chaque patch non upstream est une « dette technique » — il fonctionne aujourd’hui, mais demain, à la prochaine mise à jour du noyau, il peut tout simplement casser. Et si ce patch concerne une fonction de sécurité, le prix de la casse n’est pas un simple bug : c’est une confiance brisée.
Pour conclure, empruntons une phrase citée par Ingo dans son fil Mastodon d’origine : « Un argument technique avancé par un auteur en qui l’on a confiance, difficile à vérifier, et qui ressemble à un argument déjà connu comme correct, ne sera presque jamais examiné en détail. » Le code ne fait pas exception.
Liens de référence
- Fil Mastodon original d’Ingo Blechschmidt (témoignage de première main)
- Discussion Hacker News (379 points / 182 commentaires)
- Commit du noyau à l’origine de la vulnérabilité a28d893eb327
- Correctif du noyau soumis par Ingo
- Test automatisé NixOS (empêche la réapparition de la vulnérabilité)
- Correctif du mécanisme d’avertissement de cryptsetup (MR #936)
- Article d’analyse de la communauté Sesame Disk
- Analyse technique de Hack’n Jill