Loading story…
A security flaw affecting Linux systems that use LUKS disk encryption with the cryptsetup-suspend mechanism can leave volume keys accessible in memory instead of removing them during suspend operations. The issue stems from a regression introduced in Linux kernel 6.9, causing cryptsetup luksSuspend to fail to fully clear encryption keys from the kernel keyring, where they may remain visible through /proc/keys and potentially be extracted by a local attacker.
The exposure is significant for systems that rely on suspending encrypted volumes before sleep or hibernation, including deployments on distributions such as Debian and NixOS. A fix was prepared in cryptsetup rather than in the kernel and is expected in cryptsetup 2.8.7; the reports also note that NixOS had previously disabled related hibernation functionality by default because of older concerns about secrets persisting in memory after resume.
Mallory correlates global threat intelligence with your attack surface — know if you’re exposed before adversaries strike.
6 events from the most recent confirmed update back to the earliest known activity.
On 2026-06-30, Ingo Blechschmidt published an experimental NixOS project called secure-suspend that applies a kernel patch and custom suspend flow to wipe LUKS keys from memory before suspend-to-RAM and restore them on resume. The write-up also warned that Linux 6.9+ can retain an extra copy of the volume key in memory until fixed packages such as cryptsetup 2.8.7 are available.
On 2026-06-27, cryptsetup merged a change to load volume keys into an intermediary keyring linked to the thread keyring, mitigating unintended persistence of LUKS volume keys caused by kernel keyring handling. The merge request also added tests to verify cleanup of volume keys and intermediary keyrings after process exit and crypt_free().
On 2026-06-17, Ingo Blechschmidt submitted a Linux kernel patch to device-mapper to stop table device opening from retaining the caller's thread keyring, which left an extra recoverable copy of the LUKS volume key in RAM until luksClose. The patch restores pre-v6.9 behavior by using kernel credentials and was marked for stable consideration.
A fix was prepared in cryptsetup rather than in the Linux kernel to address the issue where luksSuspend could leave encryption keys accessible in the kernel keyring. The correction is expected to ship in cryptsetup version 2.8.7.
A regression introduced in Linux kernel 6.9 caused "cryptsetup luksSuspend" to fail to properly remove LUKS encryption keys from kernel memory, potentially leaving them visible via /proc/keys for local extraction from RAM.
NixOS had previously disabled a related hibernation configuration because of an older issue involving secrets remaining in memory after resume. The references anchor this earlier concern to 2015.
Vulnerabilities, threat actors, malware, products, organizations, and breaches Mallory has linked to this story.
10 references tracked. Mallory keeps watching after this page renders.
codeberg.org
Open sourcegitlab.com
Open sourcegitlab.com
Open sourcemathstodon.xyz
Open sourceopennet.ru
Open sourceopennet.me
Open sourcegit.kernel.org
Open sourcegitlab.com
Open sourceMap indicators from this story to your assets and identify affected systems in minutes.
Every observed campaign, victim, and pivot linked to actors named in this story.
Malware, exploits, and IOCs connected to the activity described here.
YARA, Sigma, and Snort rules deployed to your SIEM as soon as they’re published.
Get matching new stories delivered to your team as they break — not the next morning.
Ask questions about this story and take action on the answers.
Other stories Mallory is tracking that overlap on entities, sources, or topic labels.
Multiple vulnerabilities were discovered in the use of LUKS2 disk encryption within confidential computing systems, allowing attackers with write access to storage disks to extract or modify confidential data. These flaws stem from malleable metadata headers in LUKS2, which can be exploited to trick trusted execution environment (TEE) guests into encrypting data with a null cipher, effectively disabling encryption. The vulnerabilities impact several confidential computing frameworks, including Edgeless Constellation, and are tracked under CVE-2025-59054 and CVE-2025-58356. Affected projects have released patches, and users are advised to update to the latest versions and ensure remote attestation reports reject pre-patch versions. Specifically, the Constellation Confidential Kubernetes platform was found to allow insecure use of LUKS2-encrypted persistent storage partitions. Due to unsafe handling of null keyslot algorithms in cryptsetup versions prior to 2.8.1, Constellation's CVM image could treat unencrypted volumes as confidential, exposing sensitive data. The vulnerability is addressed in Constellation version 2.24.0 and cryptsetup 2.8.1. There is no evidence of exploitation in the wild, but organizations using these frameworks should apply mitigations immediately to prevent potential data compromise.
Jun 29, 2026
Researchers and vendors disclosed **CVE-2026-46333**, a Linux kernel flaw in `__ptrace_may_access()` that lets an unprivileged local user exploit a process-exit race to bypass authorization checks and steal file descriptors from privileged processes. The bug has existed since Linux `v4.10-rc1`, and exploitation became more practical with `pidfd_getfd()` introduced in `v5.6-rc1`. Qualys and public proof-of-concept authors showed the issue can expose `/etc/shadow`, leak OpenSSH host private keys through `ssh-keysign`, and in some cases execute commands as root via targets including `chage`, `pkexec`, and `accounts-daemon` on default Debian, Ubuntu, Fedora, AlmaLinux, and other distributions. Linus Torvalds merged the upstream fix in commit `31e62c2ebbfdc3fe3dbdf5e02c92a9dc67087a3a`, and stable kernel updates were released across multiple branches as distributions began shipping patched packages. Public exploit code appeared almost immediately after the fix became visible, increasing the urgency for defenders to patch and reboot affected systems, rotate potentially exposed **SSH host keys** and other credentials, and review systems for local privilege-escalation activity. Where immediate patching is not possible, several vendors and Qualys said raising `kernel.yama.ptrace_scope` to `2` or `3` can block known exploit paths, although maintainers cautioned that such settings are only a temporary workaround and may disrupt debugging tools.
Jul 23, 2026
Public proof-of-concept exploit code was released for **DirtyDecrypt** (`CVE-2026-31635`), a high-severity Linux kernel local privilege escalation flaw caused by a missing copy-on-write guard in `rxgk_decrypt_skb()` within the RxGK subsystem. The bug allows unprivileged local users to corrupt shared page-cache memory tied to privileged files or processes, potentially overwriting targets such as `/etc/shadow`, `/etc/sudoers`, or SUID binaries to gain **root**. Reports said the issue was quietly patched upstream in late April and primarily affects systems using mainline or rolling-release kernels with `CONFIG_RXGK` enabled, including **Fedora**, **Arch Linux**, and **openSUSE Tumbleweed**; the risk is elevated on Kubernetes worker nodes and developer workstations because exploitation can also enable container escape and theft of secrets or runtime sockets. At the same time, researchers disclosed **PinTheft**, another Linux local privilege escalation exploit that abuses a double-free or refcount bug in the **RDS zerocopy send path** and uses `io_uring` fixed buffers to turn the flaw into a page-cache overwrite against a SUID-root binary. The exploit, credited to Aaron Esau of V12 Security, reportedly drains page references through failed RDS zerocopy sends, frees the page, reclaims it as page cache, and overwrites it with a malicious ELF payload that yields a root shell when executed. Mailing list discussion said a patch and proof of concept are available, with exploitability depending on the `rds` kernel module being present or autoloadable; **Arch Linux** was reported to enable it by default, while Fedora may also be exposed and Debian and Ubuntu appear to have mitigations that restrict autoloading.
Jun 29, 2026