Linux Kernel Regression: LUKS Encryption Keys Not Wiped on Suspend

A regression introduced in Linux 6.9 (May 2024) caused LUKS disk-encryption keys to remain resident in memory during suspend-to-RAM, effectively disabling the security mechanism intended to wipe these keys. This vulnerability left encrypted data susceptible to exfiltration via cold boot attacks or other RAM-dumping techniques if a laptop was seized while powered on in a suspended state.

The Root Cause: A Silent Refactoring Failure

Contrary to the expectation that encryption keys should be dropped upon thread exit, a refactoring of block device access in the kernel caused the key-wiping tool to fail silently. The issue was traced back to a specific kernel commit that ported block device access to files, which had an unexpected long-range interaction with the encryption code.

Because the system continued to function normally—meaning the laptop still suspended and resumed without error—the regression remained undetected for over two years. As noted by community members, security bugs of this nature often do not announce themselves because they do not cause system crashes or functional failures.

Detection and Mitigation

The vulnerability was discovered by Ingo Blechschmidt through a combination of source code analysis and memory forensics. While attempting to integrate a Debian-inspired cryptsetup-suspend tool into NixOS, Blechschmidt noticed that entries in /proc/keys remained visible even when the documentation stated they should have been dropped. He confirmed the bug by running a virtual machine in QEMU and dumping the memory, which revealed the volume key still present in RAM.

Current Fixes and Workarounds

• Kernel Patch: A one-line kernel patch was developed to address the common case of encrypted volumes on physical block devices. However, it was later noted that this patch is incomplete as it does not cover virtual loop devices.
• Cryptsetup Update: Ondrej Kozina of the cryptsetup team developed a workaround that avoids the kernel bug. This fix is scheduled for the cryptsetup 2.8.7 release.
• NixOS Implementation: An experimental "secure suspend-to-RAM" project has been released for NixOS, which resurrects an old kernel patch by Pali Rohár to wipe LUKS keys on suspend.
• Alternative Power States: Users concerned about this vulnerability can use suspend-to-disk (hibernation). Unlike suspend-to-RAM, hibernation writes the RAM contents to an encrypted swap partition and powers off the memory, ensuring keys are not left in plaintext RAM.

Threat Model and Technical Context

The primary threat addressed by this fix is the cold boot attack, where an attacker with physical access to a powered-on (but suspended) machine can dump the contents of the RAM to recover encryption keys.

Community Perspectives on Memory Security

Technical discussions around this bug highlighted several layers of defense-in-depth strategies:

"If your CPU supports it, enable memory encryption... No plaintext leaves the CPU package. DIMM swap attacks become useless."

Other users suggested utilizing TPM features such as MemoryOverwriteRequestControl to ensure memory is wiped on boot. There was also a debate regarding the scope of the bug; some argued that because cryptsetup luksSuspend is largely a Debian-specific extension rather than a core upstream Linux feature, the impact was limited to specific distributions.

Summary of Remediation

Method	Security Level	Convenience
Suspend-to-RAM (Unpatched)	Low (Keys in RAM)	High
Suspend-to-RAM (Patched)	Medium (Keys wiped)	High
Hibernate (Suspend-to-Disk)	High (RAM powered off)	Medium
Hardware Memory Encryption	Very High	High