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>
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>
Default status is the baseline for the product, each version can override it (e.g. patched versions marked unaffected).
| Vendor | Product | Default status | Versions | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| Linux | Linux | unaffected |
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Linux | Linux | affected |
|
No data.
No data.
No data.
Advisories
No advisories yet.
Fixes
Solution
No solution given by the vendor.
Workaround
No workaround given by the vendor.
References
History
Wed, 24 Jun 2026 17:15:00 +0000
| Type | Values Removed | Values Added |
|---|---|---|
| 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> | |
| Title | dm cache metadata: fix memory leak on metadata abort retry | |
| First Time appeared |
Linux
Linux linux Kernel |
|
| CPEs | cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:* | |
| Vendors & Products |
Linux
Linux linux Kernel |
|
| References |
|
|
Projects
Sign in to view the affected projects.
MITRE
Status: PUBLISHED
Assigner: Linux
Published:
Updated: 2026-06-24T16:30:04.872Z
Reserved: 2026-06-09T07:44:35.382Z
Link: CVE-2026-53060
Vulnrichment
No data.
NVD
No data.
Redhat
No data.
OpenCVE Enrichment
No data.
Weaknesses
No weakness.