https://vulnerability.circl.lu Contains only the most 10 recent entries. http://www.rssboard.org/rss-specification python-feedgen en Fri, 02 Oct 2026 18:34:41 +0000 https://vulnerability.circl.lu/vuln/cve-2026-72103 <p><strong>Affected:</strong> Linux</p> <p>In the Linux kernel, the following vulnerability has been resolved:</p> <p>dm: avoid leaking the caller&#39;s thread keyring via the table device file</p> <p>The refactoring in commit a28d893eb327 (&#34;md: port block device access to file&#34;) accidentally causes the caller&#39;s thread keyring to be kept alive long beyond the caller&#39;s lifetime.</p> <p>As a result, &#34;cryptsetup luksSuspend&#34; silently fails to wipe the LUKS volume key from memory.</p> <p>In detail: &#34;cryptsetup luksOpen&#34; uses its supposedly ephemeral thread keyring to pass the volume key to the kernel. dm-crypt&#39;s crypt_set_keyring_key() copies the key material into its own crypt_config structure and then drops its own reference to the key in the keyring with key_put().</p> <p>With this fix, restoring pre-v6.9 behavior, the copy in the thread keyring is then promptly garbage collected, such that exactly one copy of the volume key remains. This single copy is correctly wiped from memory on &#34;cryptsetup luksSuspend&#34;.</p> <p>Without this fix, the thread keyring and the volume key in it remains. This second copy is only freed on &#34;luksClose&#34;. &#34;luksSuspend&#34; neither knows about this copy nor has any way to remove it, so the key remains recoverable from RAM after a suspend that is documented to have wiped it.</p> <p>This fix should not introduce new security problems, as the code is anyway gated by CAP_SYS_ADMIN. The device-mapper core, not the calling task, is the legitimate owner of this long-lived file.</p> <p><strong>Affected:</strong> Linux</p> <p>In the Linux kernel, the following vulnerability has been resolved:</p> <p>dm: avoid leaking the caller&#39;s thread keyring via the table device file</p> <p>The refactoring in commit a28d893eb327 (&#34;md: port block device access to file&#34;) accidentally causes the caller&#39;s thread keyring to be kept alive long beyond the caller&#39;s lifetime.</p> <p>As a result, &#34;cryptsetup luksSuspend&#34; silently fails to wipe the LUKS volume key from memory.</p> <p>In detail: &#34;cryptsetup luksOpen&#34; uses its supposedly ephemeral thread keyring to pass the volume key to the kernel. dm-crypt&#39;s crypt_set_keyring_key() copies the key material into its own crypt_config structure and then drops its own reference to the key in the keyring with key_put().</p> <p>With this fix, restoring pre-v6.9 behavior, the copy in the thread keyring is then promptly garbage collected, such that exactly one copy of the volume key remains. This single copy is correctly wiped from memory on &#34;cryptsetup luksSuspend&#34;.</p> <p>Without this fix, the thread keyring and the volume key in it remains. This second copy is only freed on &#34;luksClose&#34;. &#34;luksSuspend&#34; neither knows about this copy nor has any way to remove it, so the key remains recoverable from RAM after a suspend that is documented to have wiped it.</p> <p>This fix should not introduce new security problems, as the code is anyway gated by CAP_SYS_ADMIN. The device-mapper core, not the calling task, is the legitimate owner of this long-lived file.</p> https://vulnerability.circl.lu/vuln/cve-2026-72103