TL;DR: Since Linux 6.9 shipped in May 2024, the command that locks a sleeping laptop against an attacker who grabs it has been silently failing. The LUKS volume key, the secret that decrypts the whole drive, never left RAM after suspend. Anyone who seized a powered laptop mid-sleep could read the disk. The bug, traced to a single kernel commit, sat in stable kernels for more than two years before researcher Ingo Blechschmidt identified it through a git-bisect and pushed a one-line fix upstream. A NixOS regression test that proves the fix holds was merged on July 3, 2026.
The Encryption Key Stayed in RAM
The threat model for laptop full-disk encryption has two versions. The cold-boot version: the laptop is shut down, the screen is off, the attacker needs the drive decrypted. The at-suspend version: the laptop is asleep but still powered, the attacker grabs the closed machine and reads the memory. The first version is what LUKS is built around. The second is what suspend-to-RAM threatens, and exactly what the cryptsetup luksSuspend call is supposed to defeat [1].
That call is invoked by systemd-homed and by the standalone cryptsetup-suspend tool. When it runs successfully, the volume key is wiped from kernel memory and the encrypted volume is locked. The user resumes later, types their passphrase, and the key comes back. Since Linux 6.9, that wipe has silently failed: the command returns success, the key never leaves RAM [1]. A powered, seized laptop is now a key-bearing laptop for the length of battery life.
The window is not small. Blechschmidt described the discovery as "trusting a security mechanism for years and learning it was never doing the thing" [1].
How a Bug Bisect Caught It
Ingo Blechschmidt, a contributor best known for NixOS and the secure-suspend side project, found the regression after a few days of debugging and a long git-bisect [1]. The bisect pinned the regression to the kernel commit that introduced the change, which Linux 6.9 shipped with in May 2024, and from there the breakage stayed in every stable kernel since.
Blechschmidt published his findings on Mathstodon on June 18, 2026, under the handle @iblech, along with the suspected commit and the one-line patch he drafted [1]. He also linked a NixOS pull request that adds a regression test, and a cryptsetup merge request that adds an explicit warning when the wipe step cannot reach memory [1]. The NixOS PR was merged on July 3, 2026 [2].
The Kernel Change Behind It
The culprit, upstream commit a28d893eb3270cf62c10dd8777af0d8452cdc072, is titled "md: port block device access to file" [1]. Blechschmidt described the change as "a sensible and useful refactoring" with an "unexpected long-range interaction with the encryption code" [1]. The MD subsystem rewrote how it talked to block devices. Somewhere in the resulting indirection, the path that cryptsetup luksSuspend walks to reach the volume key no longer reached memory the wipe could target.
This is the failure mode that makes Linux security so fragile. A well-reasoned, code-reviewed refactor in a subsystem most LUKS users never read breaks the exact invariant the encryption layer assumes. The change shipped because the refactor was reviewed for what it set out to do, not for what it silently changed for other layers. The kernel log shows no failure. The lock command returns success. There was nothing to see.
One-Line Fix, One-Day Test
The fix, posted to the kernel mailing list at lore.kernel.org, is one line [1]. Blechschmidt was clear that the patch should not be treated as audit-complete: "without formal proofs I cannot say whether my patch is correct and free of its own long-range interactions" [1].
The NixOS regression test, NixOS/nixpkgs PR #532499, automates the wipe verification. It opens a LUKS volume, calls luksSuspend, then reads kernel memory to confirm the volume key is gone. On current buggy kernels the test fails. On the linux_6_6 package it passes [2]. PR #532499 was merged into NixOS master on July 3, 2026 [2]. A companion change, cryptsetup merge request #936, asks cryptsetup to emit a warning instead of returning success when the wipe step cannot find the volume key [1].
The PR description also includes an unusually candid note on whose problem this is. "The cryptsetup people might say 'it's a kernel issue' ... while the kernel people might say 'it's a cryptsetup issue' ... and the systemd people might say 'it's a joint cryptsetup+kernel issue'" [2]. The maintainer-merge rationale was simpler: the test catches regressions from any of the three layers at once.
Who This Actually Puts at Risk
The headline audience is anyone using a Linux 6.9 or newer kernel with LUKS on a laptop who treats suspend as a security event. That is most of the encrypted-Linux-laptop population. The vulnerability only matters when an adversary gets the device while it is asleep and powered: border crossings, police seizure, hotel-room intrusions, opportunistic theft of an open laptop bag. For a journalist whose notes never leave an encrypted volume, an activist with locally stored contacts, or any user running Qubes or Tails on a laptop that lives in a backpack, that threat model is the reason they encrypted in the first place.
Blechschmidt recommends full-disk encryption "to everyone" and notes that under Windows the canonical tool for this is VeraCrypt [1]. Full-disk encryption is not broken: full shutdowns still wipe RAM. The at-suspend tier of that protection silently failed for two years, and distributions have not yet shipped the fix.
What to Watch
The patch needs to land in a stable kernel release. Until then, distributions carrying Linux 6.9 or newer are exposed. Users who depend on suspend-as-security should treat sleep as compromised for now: full shutdown before any device-handover event, including crossings, repairs, and unattended bags.
Watch for the cryptsetup MR #936 warning to land upstream, the NixOS PR #532499 regression test to catch any reintroduction (for example via cryptsetup's --link-vk-to-keyring option), and Blechschmidt's planned security.secureSuspend.enable module to ship [1][2]. Each is a real-world check on whether the fix holds across the three layers, and whether a distribution later re-enables the leak through a configuration option the kernel patch would have otherwise closed.