If you use full disk encryption with LUKS and your machine goes to sleep, you’re counting on a specific protection: wiping encryption keys from RAM. Since Linux kernel 6.9, that protection no longer works. This is a silent regression, with no official announcement and no CVE published as of this writing.
LUKS suspend: why wiping keys from memory matters
Disk encryption with LUKS relies on dm-crypt, the Linux kernel’s encryption subsystem. While the system is running, decryption keys are loaded into RAM. That’s unavoidable: the kernel needs them to read and write encrypted data on the fly.
The problem shows up at suspend time. A suspended machine keeps its RAM contents intact. An attacker with physical access can pull off a cold boot attack: by cooling the memory modules or quickly transferring them to another system, they can extract their contents, encryption keys included.
The LUKS suspend feature existed precisely to counter this scenario. Before suspending, it would wipe keys from RAM. On wake, the system would prompt for a passphrase to reload them. It’s a comfort-vs-security tradeoff, but it was a documented, deliberate choice that users could make.
The regression introduced in Linux 6.9
Since kernel version 6.9, that wipe no longer happens. Encryption keys remain in memory during and after suspend. The expected behavior of LUKS suspend is no longer honored.
The alarm was raised on June 18, 2026 by Ingo Blechschmidt, on the Mathstodon social network. The Privacy Guides community picked up the topic on July 2, 2026. These are technical and privacy-oriented channels, not kernel mailing lists.
That’s what makes this particularly concerning. No visible discussion on the LKML, no fix commit identified, no CVE assigned, no public response from dm-crypt subsystem maintainers. The regression appears to have slipped under the radar of official channels.
What this actually means for users
If you’re running kernel 6.9 or later and using LUKS with suspend, here’s the real situation:
- Your encryption keys stay in RAM while the machine is suspended.
- Physical access to a suspended machine potentially exposes those keys.
- The cold boot attack protection you thought you had is no longer active.
- No official fix or documented workaround has been announced at this stage.
Affected distributions include all those running kernel 6.9 or newer: recent versions of Arch Linux, Fedora, and potentially Debian testing or Ubuntu with the HWE kernel fall within scope. The exact suspend configurations affected (suspend-to-RAM, suspend-to-disk) still need to be clarified in a formal bug report.
What’s still missing to assess the real severity
Available information remains incomplete. Several key points haven’t been publicly documented yet:
The specific commit responsible for the behavior change since Linux 6.9 hasn’t been identified in available sources. Without that commit, it’s hard to tell whether this is an accidental regression or a deliberate architectural change that was poorly documented.
No bug report has been filed publicly on the kernel bugzilla or the cryptsetup repository, at least within the available observation window. That’s unusual for a regression of this nature.
Finally, no impact assessment from major distributions has been published. Debian, Fedora, and Arch all have responsive security teams: their relative silence may indicate the issue hasn’t reached those channels yet, not that it’s unimportant.
What to do while waiting for a fix
With no confirmed patch available, the sensible posture is to treat this risk as unmitigated on kernels 6.9 and later. A few practical options:
- Prefer hibernation (suspend-to-disk) with an encrypted swap partition, which avoids leaving the machine in a prolonged RAM suspend state.
- Shut the machine down completely rather than suspending it in high-risk contexts (travel, uncontrolled physical access).
- Watch the cryptsetup repository and your distribution’s security announcements for any patch.
- Monitor the LKML and kernel bugzilla to track progress on an official report.
This isn’t a solution, it’s exposure reduction while you wait for something better.
Key takeaways
- Since Linux 6.9, LUKS suspend no longer wipes encryption keys from RAM on suspend, which cancels cold boot attack protection.
- The regression was publicly reported in June 2026 by Ingo Blechschmidt, with no visible official response from maintainers as of this writing.
- No CVE, no patch, and no official bug report have been published within the available observation window.
- LUKS users with suspend enabled on kernel 6.9 and later should treat this risk as active and unmitigated.
- The priority is to monitor cryptsetup, the LKML, and security bulletins from major distributions.
If you manage Linux workstations with LUKS encryption in a professional environment, this deserves immediate attention. Feel free to reach out or follow the blog for updates on this topic.
Sources
- Privacy Guides Community, discussion from July 2, 2026: https://discuss.privacyguides.net/t/since-linux-6-9-luks-suspend-stopped-wiping-disk-encryption-keys-from-memory/38949
- Original post by Ingo Blechschmidt on Mathstodon (@iblech@mathstodon.xyz), June 18, 2026
- cryptsetup repository (reference for tracking a potential fix): https://gitlab.com/cryptsetup/cryptsetup