For two years, a Linux change left disk-encryption keys sitting in RAM through suspend
The whole point of wiping the key before suspend-to-RAM is so a stolen, sleeping laptop can't give it up. Since Linux 6.9, security researcher Ingo Blechschmidt reports, that wipe silently stopped happening — for over two years.
The mechanism at issue is cryptsetup's luksSuspend, which is supposed to scrub the master key from memory before sleep. The claim: it quietly stopped, leaving the key resident and, in the post's words, 'for the taking by anyone who seized the still-powered laptop.'
The thread's corrections matter as much as the bug. Several readers noted luksSuspend is a Debian extension, so the headline overstates a kernel-wide flaw. Others questioned the threat model — a locked laptop isn't trivially readable by 'anyone' — and the most practical fix offered was to hibernate: power the RAM off and the whole class of cold-boot attack goes away.
The regression, and the caveats that come with it
The post — by Ingo Blechschmidt (mathstodon.xyz/@iblech) — reports that since Linux 6.9, the cryptsetup luksSuspend path that is meant to wipe the LUKS master key from RAM before a suspend-to-RAM silently stopped doing so, leaving the disk-encryption key resident in memory across suspend for more than two years. As one reader quoted the source: the key "remained resident in memory across suspend, leaving it there for the taking by anyone who seized the still-powered laptop." A NixOS test was reportedly added to catch the regression going forward. (The Mastodon source didn't render for this edition, so treat the specifics as reported-not-verified.)
Two corrections from the thread reframe the severity. First, scope:
"this
cryptsetup luksSuspend… is not really officially supported but an extension done in Debian, so if anything this regression only affected Debian?… from the title it seems to be a widespread issue, not something that affects only one Distro." — a reader who traced the mechanism to a Debian-specific extension
Second, the threat model:
"Obviously, the laptop is locked when it resumes, how is that key "for the taking by anyone"? I'm not saying it is impossible to read out RAM from a locked laptop, but surely not by "anyone"." — a commenter questioning the practical exploitability
The fix most people can actually use
The recurring practical advice was to stop relying on key-wiping at all and just cut power to the memory:
"On my laptop with Fedora I just configured Linux to hibernate to disk after 15 minutes of suspend. Powering memory off ensures that bugs like this Debian-specific would not matter… So hibernating is really the only proper way to protect against cold boot." — a Fedora user who auto-hibernates as a mitigation
Others reached lower in the stack, enabling Intel's total memory encryption so no plaintext ever leaves the CPU package. The lesson isn't "Linux 6.9 broke encryption for everyone" — it's narrower and more unsettling: a safety step that runs invisibly, on a rarely-tested code path, can stop working and nobody notices for two years. Security that depends on a wipe you can't see is security you should assume is one regression away from off.
Get breakdowns like this every day
The top Hacker News stories, unpacked — by email, Telegram, or RSS.
Someone translated the entire Rust compiler into 46 million lines of C
crustc is rustc — the whole thing — rendered as roughly 46 million lines of C that build with GCC and make. It's a demo of a three-year Rust-to-C project whose real payoff is putting Rust on hardware that has no modern compiler backend.