By ByteBot
Since Linux kernel 6.9, released in May 2024, cryptsetup luksSuspend — the command that wipes LUKS disk-encryption keys from RAM on system suspend — has silently stopped working. The regression surfaced this week on Hacker News with 483 points and 208 comments. Users who relied on this for cold-boot attack protection spent two years assuming their keys were being wiped. They weren’t.
The most alarming part is the false sense of security: on resume, the system still prompts for a LUKS passphrase — exactly the expected behavior. That prompt does not mean the keys were cleared. It can appear regardless of whether the wipe step succeeded. Users had no visible indication anything had broken.
How Linux Kernel 6.9 Broke the LUKS Memory Wipe
cryptsetup has loaded LUKS volume keys in the kernel thread keyring since v1.1.0, released in 2009. The design relied on a documented guarantee: “A thread keyring is destroyed when the thread that refers to it terminates.” When the cryptsetup process exited after decrypting the drive, the thread keyring — and with it, the volume key — would be destroyed automatically. This 15-year-old assumption worked correctly until cryptsetup luksSuspend met kernel 6.9.
A kernel refactoring in 6.9 altered the lifetime behavior of thread keyring keys. After this change, thread keyring keys were no longer automatically destroyed on thread exit. The volume key persisted in kernel memory. luksSuspend suspended I/O operations as expected, but the key wipe step silently failed because the implicit cleanup it depended on no longer happened. The correct fix requires cryptsetup to explicitly zero the volume key from userspace rather than relying on kernel housekeeping. A regression test has been added to the cryptsetup project to prevent recurrence, but a patched release has not yet shipped widely.
Cold Boot Attacks: The Threat LUKS Suspend Was Built to Stop
A cold boot attack is a physical attack where an adversary with brief access to a suspended laptop rapidly cools the RAM modules — or simply reboots the machine — to preserve memory contents, then dumps that memory to recover encryption keys. DRAM retains data for seconds to minutes after power loss when cooled. F-Secure demonstrated stealing encryption keys from a suspended laptop in under two minutes. This is not a theoretical attack.
LUKS suspend was specifically designed for this threat model: a journalist closes a laptop quickly at a border crossing; the keys vanish from memory; the attacker gets the device but cannot read the drive without the passphrase. That protection failed silently for anyone running kernel 6.9 or later. The users most likely to configure cryptsetup-suspend are exactly the users who face elevated physical access risk — which makes the two-year false-security window especially damaging.
Are You Affected?
The regression directly affects users of the cryptsetup-suspend Debian package and anyone who configured luksSuspend as part of their systemd suspend hooks on Arch Linux, openSUSE, or similar distributions. Standard suspend setups that never used this opt-in feature are unaffected — though those users never had cold-boot protection to begin with.
To check if you are affected: if you explicitly installed cryptsetup-suspend or set up a pre-suspend hook calling luksSuspend, and you are running kernel 6.9 or later, your key wipe has been silently failing. The affected range is kernel 6.9 (May 2024) through at least the current stable series as of this writing.
Use Hibernation: The Safe Workaround Until a Patch Lands
The immediate workaround is hibernation (suspend-to-disk) rather than suspend-to-RAM. Hibernation writes system state to disk and powers off RAM entirely. No encryption keys remain in memory. An attacker with physical access to a hibernating laptop faces a completely powered-off memory subsystem — there is nothing to extract. The protection is reliable regardless of kernel version.
For users who require suspend-to-RAM specifically, the only option right now is to wait for a patched version of cryptsetup that explicitly zeros the volume key in userspace rather than relying on kernel cleanup. Watch the cryptsetup-suspend package changelog and your distribution security advisories. Until the patch is deployed, treat suspend-to-RAM as offering no cold-boot protection on kernels 6.9 and later.
Key Takeaways
- Since kernel 6.9 (May 2024),
cryptsetup luksSuspendhas not wiped LUKS encryption keys from RAM — the wipe silently failed for two years - The passphrase prompt on resume is not proof the keys were wiped; users had no visible indication of the regression
- Affected users: anyone running
cryptsetup-suspendor explicitluksSuspendhooks on kernel 6.9+, including Debian, Arch Linux, and openSUSE users - Switch to hibernation (suspend-to-disk) immediately if cold-boot protection is required — it powers off RAM entirely and is safe on any kernel version
- A fix requires
cryptsetupto explicitly zero keys in userspace; watch your distribution package changelog for a patched release
