Linux 6.9 broke LUKS suspend key-wiping — silently, for two years

What happened

On a Mastodon thread that made the front page of Hacker News at 443 points, mathematician Ingo Blechschmidt (@iblech) walked through a git-bisect saga that ended somewhere nobody wanted it to end: a one-line kernel refactor from May 2024 had silently broken `cryptsetup luksSuspend` on every Linux distribution shipping kernel 6.9 or newer.

The purpose of `luksSuspend` is narrow but important. When you close your laptop lid, the machine goes to suspend-to-RAM. The LUKS master key — the thing that decrypts your entire disk — stays resident in kernel memory, because otherwise the disk would be unreachable on resume. `luksSuspend` is the workaround: freeze the block device, wipe the key from memory, and require the passphrase again on resume. It's the difference between "an attacker who grabs your still-powered laptop can dump RAM and get the key" and "an attacker who grabs your still-powered laptop gets a locked device."

Since kernel 6.9, that wipe silently did nothing. The refactor in commit `a28d893eb3270` was clean, sensible, and in isolation correct. But it had a long-range interaction with the dm-crypt keyslot code that meant the key material stayed put. No error was raised. No log line appeared. `cryptsetup luksSuspend` returned 0. The device looked suspended. The key was still there for anyone with a cold-boot attack, a DMA exploit, or a friendly forensics kit.

Why it matters

Blechschmidt's own phrasing is the sharpest summary anyone's written of this class of bug: *"A technical argument by a trusted author, which is hard to check and looks similar to arguments known to be correct, is hardly ever checked in detail. The same, it seems, is true for computer code."* Two years. No test. No user complaint loud enough to bisect until now. The fix, once found, is one line — merged at [lore.kernel.org/all/ajKwRtP8izwRsMmv@quasitopos](https://lore.kernel.org/all/ajKwRtP8izwRsMmv@quasitopos/).

The HN thread produced the expected pushback, and it's worth engaging honestly. Commenter `kokada` argued the framing is clickbait because `luksSuspend` isn't an upstream-supported cryptsetup subcommand — Debian ships the integration, most distros don't wire it into their suspend hooks by default. That's technically true and materially misleading. If you use full-disk encryption on Linux and expected lid-close to protect the key, you probably weren't checking whether your distro maintained the hook — you assumed the security property held. NixOS did wire it up. So did custom Arch and Debian setups. The kernel change broke all of them the same way.

Other commenters made the more defensible point that most users don't have this threat model at all. `tombert` noted he encrypts his disk mainly so he can resell a laptop without wiping tax records. Fair — for that threat model, the key living in RAM during suspend is irrelevant. But for the model where the bug actually matters (border crossings, journalists in hostile jurisdictions, anyone with a real evil-maid concern), the failure mode is exactly the one you'd design a security review to catch: the mechanism silently no-op'd while presenting a successful interface.

The uncomfortable part isn't that a bug existed. It's that the only reason we know about it is one user's paranoia and patience with `git bisect`. There was no regression test in the kernel. No integration test in cryptsetup. No CI in any major distro that booted a VM, suspended it, and checked whether the LUKS key had actually left memory. The one-line fix ships alongside two things that should have existed already: an automated NixOS test ([nixpkgs #532499](https://github.com/NixOS/nixpkgs/pull/532499)) and a cryptsetup patch ([MR 936](https://gitlab.com/cryptsetup/cryptsetup/-/merge_requests/936)) that emits a warning instead of failing silently. Both are landing now. Neither existed for the two years the bug was live.

What this means for your stack

First, the practical checklist. If you're on Linux with LUKS full-disk encryption and your threat model includes physical seizure of a powered-on laptop:

- Hibernate, don't suspend. Suspend-to-disk writes RAM (encrypted, if you have the encrypted swap set up right) to disk and powers off. Suspend-to-RAM keeps the key resident. During the two-year window, only hibernate actually protected you. - Check your kernel and cryptsetup versions. The upstream fix is in the lore.kernel.org thread linked above. Distros will backport at their own pace — Fedora and Arch move fast, Debian stable will take longer. - If you're on NixOS, the test is landing. Other distros should be pressured to add equivalent CI. - Assume this class of bug exists elsewhere. Any security mechanism that runs on a code path humans don't exercise interactively — like key-wipe on suspend — should be treated as broken until a test proves otherwise.

Second, the meta-lesson for anyone maintaining crypto code. The refactor that caused this was good code by every normal metric: it simplified an interface, removed duplication, made the surrounding subsystem easier to reason about. It didn't touch the encryption code. It touched a code path that the encryption code depended on in a non-obvious way. This is the exact shape of vulnerability that formal methods advocates keep pointing at — and while nobody's going to formally verify the entire block layer any time soon, the case for property-based tests around security-critical invariants ("after `luksSuspend`, the key bytes are not present in any kernel allocation") gets stronger every time one of these bugs surfaces.

Third, and this is where the HN comments got interesting: `moktonar` asked whether this was a "bugdoor" — an intentionally-introduced weakness with plausible deniability. That's almost certainly wrong here. The commit history is public, the author is known, the interaction is exactly the kind of subtle coupling that produces real bugs. But the fact that the question gets asked at all is the tell. When a security primitive silently fails for two years across every mainstream distro, the difference between incompetence and malice becomes epistemically indistinguishable from the outside. That's a bad place for open-source crypto tooling to be.

Looking ahead

The fix will land. The regression test will catch the next one of these. But the interesting question is how many other silent-failure modes exist in the security stack right now — mechanisms that return success codes while doing nothing, because nobody wrote the test that would notice. If you maintain any code where the failure mode is "the security property doesn't hold but the interface says it does," this is your reminder to write that test today. Not next sprint. Today.