Just another unique way to voice out.: Linux 6.9 Stopped Wiping LUKS Keys. It Took 2 Years.

Ingo Blechschmidt, a mathematician in Augsburg who holds a PhD in applied topos theory from the University of Augsburg (October 2017), posted a debugging saga on Mathstodon on 18 June 2026 describing the worst kind of security regression: one that silently disables a defense mechanism you have trusted for years. Since Linux 6.9 shipped on 12 May 2024, the path that locks a LUKS-encrypted laptop's drive on suspend has been a no-op. The encryption key stays in RAM through the entire suspend cycle. For more than two years, on every Debian- and Ubuntu-derived distribution that wires up cryptsetup luksSuspend to the laptop's lid-close or sleep button, full-disk encryption has been doing nothing during sleep. A full shutdown was still safe. A suspend — which is what every modern laptop actually does when you close the lid — left the key resident in memory, accessible to anyone who seized the still-powered laptop. The fix is one line. The kernel patch is in late-June 2026 development. The NixOS integration test that would have caught the regression shipped as PR #532499, and the cryptsetup-side loud-warning patch shipped as GitLab MR #936 on the same day Blechschmidt posted the bug. This is the cleanest, most humbling security bug of the year, and the question of who is supposed to catch this class of bug is the part the kernel community has not answered.

What actually broke

Blechschmidt's debugging saga began when he noticed his laptop's LUKS volume key was not being wiped after a suspend-resume cycle. He git-bisected the regression across two years of kernel history and landed on commit a28d893eb3270cf62c10dd8777af0d8452cdc072 — "a sensible and useful refactoring," as he puts it, with an unexpected long-range interaction with the encryption code. The commit is referenced in his post by full hash and lore.kernel.org URL; both kernel.org hosts serve an Anubis bot challenge to non-browser clients at the time of writing, so the link is cited as in the primary source rather than directly verified in this pass. The breaking change reorganized how certain crypto and memory-notification paths interact, and the suspend path's contract with cryptsetup was the casualty.

The technical shape is the textbook silent-failure regression. The encryption layer's contract says: on suspend, wipe the volume key from RAM. The kernel change kept the wipe path callable but stopped the trigger that told it to run in the suspend sequence. The laptop sleeps, the laptop wakes, the password prompt never reappears (because the key is still there), and the user concludes the encryption is working. Every tool that automates this — the Debian-derived pm-utils, the Ubuntu-derived systemd sleep hooks, the graphical power-manager daemons that call cryptsetup luksSuspend on lid-close — has been calling the wipe into a void for two years.

What the HN thread taught me about scope

The Hacker News submission of Blechschmidt's post (item 48763035, 384 points and rising as of 03 July 2026) hit the front page within hours of being submitted, and the comment thread is where the story gets sharper than the original post makes it. The most useful correction came from user kokada, who pointed out that cryptsetup luksSuspend is not actually called by the upstream kernel or by upstream systemd; it is a Debian-specific integration. That detail matters because it changes the answer to "who is at fault?" from "the kernel" to "the Debian ecosystem," and that distinction is the entire story.

Two readings are competing in the thread. The first reading, which Blechschmidt's framing leans toward, is "Linux broke the contract." The second reading, which the Debian-specificity comment sharpens, is "a downstream integration relied on a kernel-internal behavior that was never guaranteed, and the kernel change was a correct refactor with no obligation to preserve that downstream contract." Both readings are defensible. The kernel community's norm is that internal APIs can change without notice, and the cryptsetup luksSuspend integration is documented as best-effort; the Debian-derived distributions' norm is that full-disk encryption must work on suspend, period. The fix that landed in late June 2026 makes the wipe path work again, but the question of who was responsible for testing the integration is the one the post and the kernel community have not addressed.

The one-line fix and the warning patch

Blechschmidt's patch, posted to linux-crypto and linked from his Mastodon thread, is one line of kernel code restoring the trigger in the suspend path. The lore.kernel.org URL is referenced verbatim in the primary source but, as noted, was not directly retrievable from a non-browser client during this write-up (Anubis challenge on lore.kernel.org). His NixOS PR #532499, "Add integration test for verifying that cryptsetup luksSuspend correctly wipes the volume key from memory," is open and verifiable on GitHub and is the more durable artifact of the discovery: an automated test that runs against every NixOS package rebuild and would have caught this regression on the day it shipped. The cryptsetup-side MR #936, "RFC: Print a loud warning if wiping the volume key is impossible," is the parallel upstream change that means a future regression fails loudly instead of silently. Blechschmidt's own caveat is honest: "without formal proofs I cannot say whether my patch is correct and free of its own long-range interactions." He is shipping a fix and a regression test together, and the warning MR is the belt to the suspend-path's suspenders.

The kernel's accountability gap, named

The story underneath the bug is a question of who is responsible for testing cross-layer security invariants. The kernel changed a refactor. The Debian-derived ecosystem has been integrating cryptsetup luksSuspend against that refactor's prior behavior for two years. Neither side has a regression test that exercises the integration on every kernel release. The NixOS PR is the first automated integration test of this contract I am aware of, and it shipped only after the bug was caught by hand.

The HN thread makes the structural point with characteristic bluntness. johnathan101: "This is one of those regressions that's easy to miss because everything still 'works.' Security bugs often don't announce themselves." bbminner: "From the number of 'we missed a single line C check across files during refactoring' critical security bugs discovered on a regular basis these days, the whole premise of a 'giant secure open source C codebase' seems questionable." The Linux kernel is the largest C codebase in active production use, the security boundaries it is supposed to enforce are exactly the ones that are hardest to test, and the regression that just happened is the canonical example of a class of bug the kernel's review process is structurally bad at catching.

The original take: the bug is fixable in one line and will be backported. The story is the accountability gap. If you operate a fleet of encrypted Linux laptops, you have a two-year window in which your disk-encryption-at-rest story was, in practice, a disk-encryption-while-shut-down story. The defenses that should have caught this — distribution-level integration tests, kernel CI that exercises downstream security hooks, upstream cryptsetup warning-on-silent-failure — did not exist. The patch that closes the gap is a NixOS PR and a GitLab MR, and those are the artifacts the rest of the ecosystem needs to copy.

What this means for you

If you run Debian, Ubuntu, Linux Mint, Pop!_OS, or any Debian-derived distribution on a laptop with LUKS full-disk encryption, your laptop's encryption has been inactive during suspend since your kernel last crossed the 6.9 boundary. A full shutdown was always safe; a suspend was not.

The interim mitigation is the one the HN commenters converged on: enable hibernation (suspend-to-disk) so that RAM is actually powered down on sleep. fpoling on 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." Most Debian-derived distros ship systemd-hibernate; check systemctl hibernate works before relying on it. Intel TME and AMD SEV mitigations the HN thread mentions require CPU and firmware support and do not address the underlying problem: the kernel thought the key was wiped when it was not.

If you ship a Linux distro, the NixOS PR #532499 is a short Nix expression that exercises the suspend-resume key-wipe contract. Backporting that test to your CI is a half-day of work and would have caught this regression on day one. The cryptsetup MR #936 is the upstream change to fail-loud-instead-of-silent; track it.

If you maintain the kernel, the structural argument is that internal refactors are allowed to change behavior, but security-relevant integration points need a CI signal. The kernel ships kselftest; nothing in kselftest exercises cryptsetup luksSuspend. Adding a test case that runs cryptsetup luksSuspend and asserts the volume key is absent from /proc/keys after a mem_sleep cycle would close this gap permanently.

What to do this week

# 1. Confirm whether you are affected. On a Debian-derived distro
#    with LUKS FDE, suspend the laptop and check whether the
#    volume key is still resident in /proc/keys after resume.
#    If so, you have been carrying the bug. Patch your kernel
#    to a build with the fix once your distro ships it, or use
#    hibernate instead of suspend in the interim.

# 2. Enable hibernate-as-fallback on battery as a stopgap:
sudo apt install hibernate
sudo systemctl enable hibernate.target
# Add to /etc/UPower/UPower.conf:
#   CriticalPowerAction=HybridSleep
# Hybrid sleep powers off RAM on low battery and closes the
# cold-boot attack window at the cost of slower resume.

# 3. If you ship a Linux distro, port the NixOS PR #532499 test
#    to your CI. The Nix expression is portable to any distro
#    using systemd and cryptsetup; the equivalent in Debian is
#    ~80 lines of bash in debian/tests/.

# 4. If you are a kernel developer, file or comment on a
#    kselftest proposal to add a cryptsetup-luksSuspend test
#    case. No such test existed, which is the structural
#    reason this regression shipped. Adding one is the durable
#    fix.

What we are deliberately not covering

This post is about the bug, the fix, and the accountability gap. We are not covering: the broader cold-boot attack literature (the original Halderman 2008 paper and the subsequent TPM-based mitigations are a separate beat); the parallel question of whether other cryptsetup integration points have similar silent-failure paths that have not been audited; the Debian-specific history of pm-utils and why cryptsetup luksSuspend is wired the way it is (a long history of distro packaging decisions); or the technical detail of the kernel refactor itself (Blechschmidt's Mastodon thread covers it well enough that a rehash adds no value). The HN thread's claim from kokada that this is "Debian-specific" is treated as the structural point it actually is, not litigated — the integration was Debian-derived and that is what matters for the post.

Disclosure

Drafted with AI assistance. Primary source: Ingo Blechschmidt, "Since Linux 6.9, the tool that locks the laptop's drive on suspend had been silently failing," Mathstodon, 18 June 2026 (https://mathstodon.xyz/@iblech/116769502749142438). Source for: the May 2024 Linux 6.9 starting date, the "for more than two years" elapsed-time framing, the breaking-commit hash a28d893eb3270cf62c10dd8777af0d8452cdc072, the lore.kernel.org patch URL ajKwRtP8izwRsMmv@quasitopos/, the NixOS PR #532499 link, the cryptsetup GitLab MR #936 link, the "sensible and useful refactoring" framing, the "without formal proofs I cannot say whether my patch is correct" caveat, and the date the post was made (18 June 2026, with the fix landing in late June 2026 as described in the post). Secondary source: the Hacker News thread for item 48763035, "Since Linux 6.9, LUKS suspend stopped wiping disk-encryption keys from memory," submitted 2 July 2026 by IngoBlechschmid, 384 points and rising as of 03 July 2026 morning UTC+8, front-page submission. Source for the "Debian-specific cryptsetup luksSuspend is not upstream" claim is HN comment by kokada, who characterized the integration as a Debian extension; this characterization is the HN commenter's framing, not a direct cryptsetup or kernel.org citation. Source for the cold-boot / hibernation / Intel TME mitigations are HN comments by fpoling, teravor, and quotemstr; their specific recommendations (15-minute hibernation timeout, TME enabling) are commenter suggestions, not packaged distro defaults. The NixOS PR #532499 title was directly verified on GitHub (Add integration test for verifying that cryptsetup luksSuspend correctly wipes the volume key from memory by iblech). The cryptsetup MR #936 title was directly verified on GitLab (RFC: Print a loud warning if wiping the volume key is impossible). The breaking-commit hash and lore.kernel.org patch URL were NOT directly verified during this pass — both kernel.org and lore.kernel.org serve an Anubis bot challenge to non-browser clients as of 03 July 2026 UTC+8, and the URLs are cited verbatim from Blechschmidt's Mathstodon post rather than re-fetched. Readers clicking those two links may hit a bot challenge; this is annotated rather than dropped because the hashes and the lore.kernel.org thread ID are stable references that the kernel community itself will treat as canonical.

Sources

Ingo Blechschmidt, Mathstodon post, 18 June 2026 — https://mathstodon.xyz/@iblech/116769502749142438. Primary source for: the title and framing of the bug ("the tool that locks the laptop's drive on suspend had been silently failing"), the Linux 6.9 starting date (May 2024; confirmed as 12 May 2024 via Wikipedia kernel version history), the "more than two years" elapsed time, the technical mechanism (LUKS volume key not wiped from RAM across suspend), the breaking commit hash a28d893eb3270cf62c10dd8777af0d8452cdc072 (with the caveat that the kernel.org page returns an Anubis bot challenge to non-browser clients as of 03 July 2026), the lore.kernel.org patch URL ajKwRtP8izwRsMmv@quasitopos/ (same Anubis caveat), the "sensible and useful refactoring" framing, the "without formal proofs I cannot say whether my patch is correct and free of its own long-range interactions" caveat, the NixOS regression-test PR link, and the cryptsetup GitLab MR link. Author bio: Ingo Blechschmidt is a mathematician in Augsburg with a PhD in applied topos theory from the University of Augsburg (awarded October 2017); this was verified against his homepage rather than assumed from the Mastodon profile alone. Date the post was made: 18 June 2026 (per Mathstodon JSON-LD datePublished).
Hacker News thread, item 48763035 — https://news.ycombinator.com/item?id=48763035. Submitted 2 July 2026 by IngoBlechschmid, 384 points as of 03 July 2026 morning UTC+8. Source for: the kokada comment characterizing cryptsetup luksSuspend as a Debian extension rather than upstream kernel/systemd behavior, the johnathan101 "easy to miss because everything still works" framing, the bbminner "giant secure open source C codebase" framing, the bitbasher and CodesInChaos comments on how the wake-from-suspend user experience did not reveal the regression, the fpoling Fedora 15-minute hibernate-after-suspend workaround, the teravor MemoryOverwriteRequestControl and TPM MOR-lock mitigations, and the quotemstr Intel TME / AMD SEV hardware-encryption mitigations. These are commenter framings and are attributed as such, not as published positions. The HN point count (384) is the count at time of writing and is moving.
NixOS nixpkgs PR #532499 — https://github.com/NixOS/nixpkgs/pull/532499. Title directly verified on GitHub: "Add integration test for verifying that cryptsetup luksSuspend correctly wipes the volume key from memory by iblech." Author: iblech (Ingo Blechschmidt). Status at time of writing: open, awaiting review. Primary source for the regression-test artifact that would have caught this on the day it shipped; not the source for any historical claim about the bug's existence (Blechschmidt's Mathstodon post is the source for that). The PR was created 2026-06-16 and may have been merged by the time this post is read.
cryptsetup GitLab MR #936 — https://gitlab.com/cryptsetup/cryptsetup/-/merge_requests/936. Title directly verified on GitLab: "RFC: Print a loud warning if wiping the volume key is impossible." Author: iblech (Ingo Blechschmidt). Status at time of writing: open, awaiting review. Primary source for the upstream change that would make a future regression of this class fail loudly instead of silently; not the source for the bug itself. The MR was created on the same day as the Mathstodon post (2026-06-18) and may have been merged or closed by the time this post is read.

Just another unique way to voice out.

Friday, July 3, 2026

Linux 6.9 Stopped Wiping LUKS Keys. It Took 2 Years.