{"id":6773,"date":"2026-09-04T18:49:16","date_gmt":"2026-09-04T10:49:16","guid":{"rendered":"https:\/\/www.54iter.cn\/?vuln=cve-2026-72103"},"modified":"2026-09-04T18:49:16","modified_gmt":"2026-09-04T10:49:16","slug":"cve-2026-72103","status":"publish","type":"vuln","link":"https:\/\/www.54iter.cn\/?vuln=cve-2026-72103","title":{"rendered":"CVE-2026-72103 [HIGH] &#8211; In the Linux kernel, the following vulnerability has been resolved:\n\ndm: avoid leaking the"},"content":{"rendered":"<p>In the Linux kernel, the following vulnerability has been resolved:<\/p>\n<p>dm: avoid leaking the caller&#8217;s thread keyring via the table device file<\/p>\n<p>The refactoring in commit a28d893eb327 (&#8220;md: port block device access to file&#8221;)<br \/>\naccidentally causes the caller&#8217;s thread keyring to be kept alive long<br \/>\nbeyond the caller&#8217;s lifetime.<\/p>\n<p>As a result, &#8220;cryptsetup luksSuspend&#8221; silently fails to wipe the<br \/>\nLUKS volume key from memory.<\/p>\n<p>In detail: &#8220;cryptsetup luksOpen&#8221; uses its supposedly ephemeral thread<br \/>\nkeyring to pass the volume key to the kernel. dm-crypt&#8217;s<br \/>\ncrypt_set_keyring_key() copies the key material into its own<br \/>\ncrypt_config structure and then drops its own reference to the key in<br \/>\nthe keyring with key_put().<\/p>\n<p>With this fix, restoring pre-v6.9 behavior, the copy in the thread<br \/>\nkeyring is then promptly garbage collected, such that exactly one copy<br \/>\nof the volume key remains. This single copy is correctly wiped from<br \/>\nmemory on &#8220;cryptsetup luksSuspend&#8221;.<\/p>\n<p>Without this fix, the thread keyring and the volume key in it remains.<br \/>\nThis second copy is only freed on &#8220;luksClose&#8221;. &#8220;luksSuspend&#8221; neither<br \/>\nknows about this copy nor has any way to remove it, so the key remains<br \/>\nrecoverable from RAM after a suspend that is documented to have wiped it.<\/p>\n<p>This fix should not introduce new security problems, as the code is<br \/>\nanyway gated by CAP_SYS_ADMIN. The device-mapper core, not the calling<br \/>\ntask, is the legitimate owner of this long-lived file.<\/p>\n","protected":false},"excerpt":{"rendered":"<p>In the Linux kernel, the following vulnerability has been resolved:<\/p>\n<p>dm: avoid leaking the caller&#8217;s thread keyring via the table device file<\/p>\n<p>The refactoring in commit a28d893eb327 (&#8220;md: port block de<\/p>\n","protected":false},"template":"","meta":[],"categories":[],"tags":[],"class_list":["post-6773","vuln","type-vuln","status-publish","hentry"],"_links":{"self":[{"href":"https:\/\/www.54iter.cn\/index.php?rest_route=\/wp\/v2\/vuln\/6773","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/www.54iter.cn\/index.php?rest_route=\/wp\/v2\/vuln"}],"about":[{"href":"https:\/\/www.54iter.cn\/index.php?rest_route=\/wp\/v2\/types\/vuln"}],"wp:attachment":[{"href":"https:\/\/www.54iter.cn\/index.php?rest_route=%2Fwp%2Fv2%2Fmedia&parent=6773"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.54iter.cn\/index.php?rest_route=%2Fwp%2Fv2%2Fcategories&post=6773"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.54iter.cn\/index.php?rest_route=%2Fwp%2Fv2%2Ftags&post=6773"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}