CVE-2026-53060

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> dm cache metadata: fix memory leak on metadata abort retry<br /> <br /> When failing to acquire the root_lock in dm_cache_metadata_abort because<br /> the block_manager is read-only, the temporary block_manager created<br /> outside the root_lock is not properly released, causing a memory leak.<br /> <br /> Reproduce steps:<br /> <br /> This can be reproduced by reloading a new table while the metadata<br /> is read-only. While the second call to dm_cache_metadata_abort is<br /> caused by lack of support for table preload in dm-cache, mentioned<br /> in commit 9b1cc9f251af ("dm cache: share cache-metadata object across<br /> inactive and active DM tables"), it exposes the memory leak in<br /> dm_cache_metadata_abort when the function is called multiple times.<br /> Specifically, dm-cache fails to sync the new cache object&amp;#39;s mode during<br /> preresume, creating the reproducer condition.<br /> <br /> This issue could also occur through concurrent metadata_operation_failed<br /> calls due to races in cache mode updates, but the table preload scenario<br /> below provides a reliable reproducer.<br /> <br /> 1. Create a cache device with some faulty trailing metadata blocks<br /> <br /> dmsetup create cmeta