Linux 6.9 quietly broke LUKS suspend — your keys stay in RAM

What happened

On July 1, mathematician and free-software developer Ingo Blechschmidt (@iblech) posted a short Mastodon thread that senior kernel folks are now scrambling to confirm: since Linux 6.9, the `cryptsetup luksSuspend` command no longer wipes the LUKS master key from kernel memory. The command still runs, still returns success, still freezes I/O to the encrypted device, and still asks for your passphrase on resume. What it stops doing is the one thing that made it worth running in the first place.

The reproducer is embarrassingly simple. Suspend the volume with `cryptsetup luksSuspend `, then grep `/proc/kcore` (or, on a live system, dump physical memory via any of the usual channels) for the known key bytes. Pre-6.9, the key was gone. From 6.9 onward, it is still sitting there, in plaintext, exactly where a cold-boot or DMA attacker would look for it.

The cause traces back to the dm-crypt rework that landed in 6.9, which moved the AES round-key schedule into per-CPU storage to reduce cache-line contention on high-core-count boxes. The suspend path in `dm-crypt.c` was updated to release the primary key structure, but the per-CPU shadows were never added to the teardown list. Result: on an N-core machine you can be leaving up to N copies of the key resident, and none of them are touched by the suspend ioctl.

Why it matters

LUKS suspend has always been a narrow tool for a specific threat model — the laptop lid closes, someone grabs the machine, and you want the encryption keys physically absent from RAM until you type the passphrase again. It is not a substitute for shutdown; it is a substitute for hibernate when you cannot tolerate hibernate's disk write cost or timing. For that one job, silent regression is worse than removal: users who audited the behavior in 2022 have no reason to re-audit it in 2026.

The severity depends on who you are. For a desktop user with a physically secured machine, this changes nothing — the local attacker was never in your model. For journalists, activists, sysadmins carrying prod credentials, and anyone whose $5-wrench-attack alternative is "seize the laptop while it's asleep," this is a real downgrade. The Evil Maid class of attacks against suspended LUKS volumes has been considered mitigated since roughly 2017; that mitigation is now gone on any distro shipping a 6.9+ kernel, which at this point means every actively maintained distribution.

What's notable is how the regression escaped notice for over a year. LUKS suspend has no automated test in the kernel selftests, no fuzzer coverage, and no Phoronix benchmark. Its correctness is defined by the *absence* of a byte pattern in memory, which is exactly the kind of property CI never checks unless someone writes the check. The cryptsetup project's own test suite exercises the command's exit code and I/O freeze behavior, not the memory state. This is the recurring failure mode of security features: the tests confirm the code path runs, not that the security property holds.

Community reaction on the HN thread (262 points in a few hours) split predictably. One camp: this is a bug, file it, fix it, move on. Another camp, more interesting: LUKS suspend was always a fig leaf, because dm-crypt keeps derived round keys in memory that a determined attacker can reconstruct even after the master key is purged, and because TRESOR-style register-only key storage never made it upstream. The pragmatic middle ground, articulated by a former Red Hat storage engineer in the thread: `luksSuspend` gave you a defense-in-depth win against opportunistic attackers with commodity tools, and losing that win to a silent kernel change is exactly the kind of erosion that makes threat modeling exhausting.

What this means for your stack

If you rely on LUKS suspend as part of your laptop threat model — and you should know whether you do; it is not a default, you had to configure it — assume it is broken on any machine running a 6.9 or newer kernel until proven otherwise. Concretely:

Verify on your own hardware. Suspend a test volume, then run `sudo grep -c /proc/kcore` or use `volatility` against a memory image. If you get hits, you are exposed. Do not trust distro backports without checking; the fix, if it lands, will need to touch per-CPU teardown in a way that is easy to get wrong.

Switch to hibernate-to-encrypted-swap if you can tolerate it. Hibernate flushes RAM to disk and powers off, which sidesteps the whole class of memory-resident-key attacks. The cost is 5–30 seconds of resume latency and the requirement that your swap partition be inside the same LUKS container (or a separate one with the same passphrase gating). For most laptops this is the right answer in 2026 regardless of the 6.9 regression.

If you must use suspend, shorten the window. Configure `systemd-suspend-then-hibernate` with a short timeout — 15 minutes of suspend, then automatic hibernate. You retain the fast resume for coffee-break scenarios and get the strong property back for anything longer. This is the pragmatic answer for the next 6–12 months, regardless of when the upstream fix lands.

For server and CI operators: this does not affect you unless you were doing something exotic with `luksSuspend` in an orchestration context, which is rare. The fleet-wide risk is on developer laptops, not production.

Looking ahead

Expect a patch within the week — this is the sort of regression that gets fixed fast once it's public, and the fix is mechanically obvious (walk the per-CPU array in the suspend teardown). The interesting question is whether the cryptsetup project adds a post-suspend memory assertion to its own test suite so this cannot silently regress again, and whether any distribution ships the fix as a security update rather than waiting for the next point release. The deeper lesson — that security properties defined by absence need explicit tests, and per-CPU data structures are a recurring source of state-leak bugs — will, as always, be relearned the next time someone reworks a hot path for performance and forgets that the old code was doing more than one job.