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>
Published: 2026-06-24
Score: n/a
EPSS: n/a
KEV: No
Impact: n/a
Action: n/a
AI Analysis

Impact

The Linux kernel dm-cache device‑mapper module contains a memory leak that occurs when dm_cache_metadata_abort fails to acquire the root_lock while the block_manager is created as read‑only; the temporary block_manager created outside the root_lock is not released, causing a leak that can grow with repeated aborts. This can result in gradual out‑of‑memory conditions that may destabilize or crash the kernel, leading to a denial of service. The weakness is an improper resource release, specifically a memory leak, consistent with CWE‑399. The vulnerability requires privileged manipulation of device‑mapper tables and repeated aborts in a read‑only block_manager scenario, making it an in‑kernel, local denial of service flaw.

Affected Systems

All Linux kernel releases that provide the dm-cache device‑mapper module and have not yet incorporated the fix referenced in the provided commit history are potentially impacted. The vendor is Linux:Linux, and the affected product is the Linux kernel with the dm-cache module. No specific kernel version list is supplied, so any installation that can create and manipulate dm-cache tables prior to the patch may be affected.

Risk and Exploitability

No CVSS or EPSS score is available for this entry, and the vulnerability is not listed in CISA KEV. The flaw requires privileged manipulation of the device‑mapper subsystem and repeated aborts to trigger the leak, limiting exploitation to OS administrators or compromised local users. No public exploits are known, reducing the immediate threat. Nonetheless, any system under attack could suffer a denial of service if an adversary gains the ability to reload dm-cache tables while the metadata is read‑only, repeatedly causing aborts and draining kernel memory. The absence of a remote vector and limited prerequisites keep the overall risk from high to moderate.

Generated by OpenCVE AI on June 24, 2026 at 20:54 UTC.

Remediation

No vendor fix or workaround currently provided.

OpenCVE Recommended Actions

  • Apply an updated Linux kernel that includes commit 044ca491d4086dc5bf233e9fcb71db52df32f633 (or later) fixing the dm-cache memory leak.
  • If a kernel upgrade cannot be performed immediately, disable or avoid reloading DM tables that require metadata aborts in read‑only mode; for example, skip cache table reloads while the metadata is read‑only.
  • Monitor kernel memory usage and run kmemleak or similar tools regularly to detect unreleased objects that match the crash stack trace provided in the description.

Generated by OpenCVE AI on June 24, 2026 at 20:54 UTC.

Tracking

Sign in to view the affected projects.

Advisories

No advisories yet.

History

Wed, 24 Jun 2026 21:15:00 +0000

Type Values Removed Values Added
Weaknesses CWE-399

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

Subscriptions

Linux Linux Kernel
cve-icon MITRE

Status: PUBLISHED

Assigner: Linux

Published:

Updated: 2026-06-24T16:30:04.872Z

Reserved: 2026-06-09T07:44:35.382Z

Link: CVE-2026-53060

cve-icon Vulnrichment

No data.

cve-icon NVD

No data.

cve-icon Redhat

No data.

cve-icon OpenCVE Enrichment

Updated: 2026-06-24T21:00:11Z

Weaknesses