CVE-2026-53060
Received Received - Intake
Memory Leak in Linux Kernel dm-cache Metadata Handling

Publication date: 2026-06-24

Last updated on: 2026-06-24

Assigner: kernel.org

Description
In the Linux kernel, the following vulnerability has been resolved: dm cache metadata: fix memory leak on metadata abort retry When failing to acquire the root_lock in dm_cache_metadata_abort because the block_manager is read-only, the temporary block_manager created outside the root_lock is not properly released, causing a memory leak. Reproduce steps: This can be reproduced by reloading a new table while the metadata is read-only. While the second call to dm_cache_metadata_abort is caused by lack of support for table preload in dm-cache, mentioned in commit 9b1cc9f251af ("dm cache: share cache-metadata object across inactive and active DM tables"), it exposes the memory leak in dm_cache_metadata_abort when the function is called multiple times. Specifically, dm-cache fails to sync the new cache object's mode during preresume, creating the reproducer condition. This issue could also occur through concurrent metadata_operation_failed calls due to races in cache mode updates, but the table preload scenario below provides a reliable reproducer. 1. Create a cache device with some faulty trailing metadata blocks dmsetup create cmeta <<EOF 0 200 linear /dev/sdc 0 200 7992 error EOF dmsetup create cdata --table "0 131072 linear /dev/sdc 8192" dmsetup create corig --table "0 262144 linear /dev/sdc 262144" dd if=/dev/zero of=/dev/mapper/cmeta bs=4k count=1 oflag=direct dmsetup create cache --table "0 131072 cache /dev/mapper/cmeta \ /dev/mapper/cdata /dev/mapper/corig 128 1 writethrough smq 0" 2. Suspend and resume the cache to start a new metadata transaction and trigger metadata io errors on the next metadata commit. dmsetup suspend cache dmsetup resume cache 3. Write to the cache device to update metadata fio --filename=/dev/mapper/cache --name test --rw=randwrite --bs=4k \ --randrepeat=0 --direct=1 --size 64k 4. Preload the same table dmsetup reload cache --table "$(dmsetup table cache)" 5. Resume the new table. This triggers the memory leak. dmsetup suspend cache dmsetup resume cache kmemleak logs: <snip> unreferenced object 0xffff8880080c2010 (size 16): comm "dmsetup", pid 132, jiffies 4294982580 hex dump (first 16 bytes): 00 38 b9 07 80 88 ff ff 6a 6b 6b 6b 6b 6b 6b a5 ... backtrace (crc 3118f31c): kmemleak_alloc+0x28/0x40 __kmalloc_cache_noprof+0x3d9/0x510 dm_block_manager_create+0x51/0x140 dm_cache_metadata_abort+0x85/0x320 metadata_operation_failed+0x103/0x1e0 cache_preresume+0xacd/0xe70 dm_table_resume_targets+0xd3/0x320 __dm_resume+0x1b/0xf0 dm_resume+0x127/0x170 <snip>
CVSS Scores
EPSS Scores
Probability:
Percentile:
Meta Information
Published
2026-06-24
Last Modified
2026-06-24
Generated
2026-06-25
AI Q&A
2026-06-24
EPSS Evaluated
N/A
NVD
CVE-2026-53060
EUVD
EUVD-2026-38928
Affected Vendors & Products
Showing 1 associated CPE
Vendor Product Version / Range
linux_kernel linux_kernel *
Helpful Resources
Exploitability
CWE
CWE Icon
KEV
KEV Icon
CWE ID Description
CWE-UNKNOWN
Attack-Flow Graph
AI Quick Actions
Instant insights powered by AI
Executive Summary

This vulnerability exists in the Linux kernel's device mapper cache metadata handling. Specifically, when the function dm_cache_metadata_abort is called and fails to acquire a lock (root_lock) because the block_manager is read-only, a temporary block_manager created outside this lock is not properly released. This causes a memory leak.

The issue can be reproduced by reloading a new cache table while the metadata is read-only, triggering multiple calls to dm_cache_metadata_abort. This happens due to a lack of support for table preload in dm-cache and concurrent metadata operation failures caused by race conditions in cache mode updates.

In summary, the vulnerability is a memory leak caused by improper cleanup of temporary objects during error handling in the dm-cache metadata subsystem.

Impact Analysis

The primary impact of this vulnerability is a memory leak in the Linux kernel when using dm-cache. Over time, this memory leak could lead to increased memory consumption, potentially degrading system performance or causing resource exhaustion.

Since the leak occurs during error handling in cache metadata operations, it may be triggered under specific conditions such as reloading cache tables or concurrent metadata failures, which could affect system stability or reliability.

Detection Guidance

This vulnerability can be detected by reproducing the conditions that trigger the memory leak in the dm_cache_metadata_abort function. The following commands demonstrate how to reproduce the issue and observe the memory leak using kmemleak logs.

  • Create a cache device with faulty trailing metadata blocks using dmsetup commands.
  • Suspend and resume the cache device to start a new metadata transaction and trigger metadata IO errors.
  • Write to the cache device using fio to update metadata.
  • Reload the same table with dmsetup reload.
  • Suspend and resume the cache device again to trigger the memory leak.

Monitoring kmemleak logs after these steps can help detect unreferenced objects indicating the memory leak.

Compliance Impact

The provided information does not include any details about the impact of this vulnerability on compliance with common standards and regulations such as GDPR or HIPAA.

Chat Assistant
Ask questions about this CVE
Hi! I’m here to help you understand CVE-2026-53060. Ask me anything about the vulnerability, its impact, or mitigation strategies.
0/70
EPSS Chart