dbcve.org
Linux KernelOperating system · Linux

CVE-2026-53060

MEDIUM · 5.5 CVSS v3.1 Published 2026-06-24
Fix available
A fix is available. Upgrade to 4.10 / 4.15 or later.
See remediation →
57/100
Remediation priority · Elevated
Zero-click 8 weeks old

Official description Straight from the sourceThe vendor's or NVD's own wording, published unedited. Authoritative, but often terse — it says what broke, rarely what to do.

NVD · unedited
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>

Technical summary Written by usOur analysis, written from the advisory, the CVSS vector and the affected-version data. It adds context the advisory leaves out, and never invents facts that are not in the source.

dbcve analysis · high confidence

A memory leak exists in dm_cache_metadata_abort in the Linux kernel's device-mapper cache metadata code. When the function fails to acquire the root_lock because the block_manager is read-only, a temporary block_manager created outside the root_lock is not properly released, causing memory to leak each time the function is called. The leak is confirmed via kmemleak showing unreferenced objects allocated in dm_block_manager_create.

MitigationThe kernel fix requires properly releasing the temporary block_manager in the error path of dm_cache_metadata_abort. Users can mitigate exposure by avoiding table reload operations on read-only cache metadata and monitoring for kmemleak warnings in kernel logs.

Verify against the referenced sources before acting — the references below are authoritative for this CVE, this summary is not.

Affected products & versions What the vendor confirmedThe version ranges the vendor confirmed as vulnerable. If your version sits inside a range here, treat yourself as exposed until you have upgraded.

NVD · CPE data
Linux KernelOperating system
Affected:>= 4.9.337, < 4.10>= 4.14.303, < 4.15>= 4.19.270, < 4.20>= 5.4.229, < 5.5>= 5.10.163, < 5.10.258>= 5.15.87, < 5.15.209>= 6.0.18, < 6.1>= 6.1.4, < 6.1.175>= 6.2, < 6.6.141>= 6.7, < 6.12.91>= 6.13, < 6.18.33>= 6.19, < 7.0.10

CVSS breakdown How the score is builtThe industry scoring standard. It rates how the flaw is reached, what it takes to exploit, and what an attacker gains — the score is derived from those, not the other way round.

From the vector
Attack vector
Local
Complexity
Low
Privileges
Low
User interaction
None
Scope
Unchanged
Confidentiality
None
Integrity
None
Availability
High

CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H

Am I affected? How to checkSteps we derive from the advisory and the affected-version data, so you can decide whether this CVE reaches your setup. They are a guide, not a scan — your own configuration is the authority.

dbcve checks

Work through these to decide whether this CVE applies to you.

  1. Confirm dm-cache is in use
    Run 'dmsetup status' or 'dmsetup ls' and look for devices with '_cache' in the name, or check /proc/misc for device-mapper entries. Alternatively, check if the dm-cache module is loaded with 'lsmod | grep cache'.
    Affected if No dm-cache devices or module found means this specific vulnerability does not apply to the environment.
  2. Check the running kernel version
    Run 'uname -r' to get the kernel version, then compare it against the affected ranges: >= 4.9.337 and < 4.10; >= 4.14.303 and < 4.15; >= 4.19.270 and < 4.20; >= 5.4.229 and < 5.5; >= 5.10.163 and < 5.10.258; >= 5.15.87 and < 5.15.209; >= 6.0.18 and < 6.1; >= 6.1.4 and < 6.1.175; >= 6.2 and < 6.6.141; >= 6.7 and < 6.12.91; >= 6.13 and < 6.18.33; >= 6.19 and < 7.0.10
    Affected if The kernel version falls within any of the affected ranges listed above.
  3. Identify cache target metadata state
    Run 'dmsetup status <cache_device>' for each dm-cache device to inspect metadata status. The leak triggers when metadata is in a read-only state during abort retry scenarios.
    Affected if The cache device shows read-only metadata or is in a state where dm_cache_metadata_abort would be invoked while the block_manager is read-only.

Environment is affected if dm-cache is in use, the kernel version falls within the affected ranges, and cache metadata operations encounter read-only block_manager conditions that trigger dm_cache_metadata_abort retry paths.

Generated from the published advisory. Verify against your own configuration.

Check your environment

Paste your version and any relevant configuration and it will be compared against the affected criteria above. Do not include secrets or credentials.

AI-assisted, checked against the advisory. Informational, not a guarantee.

Remediation Closing itWhat it takes to close this. Where a vendor fix exists we point at it; where none exists we say so plainly, and can build one. Effort estimates are scoped from the advisory, not from your codebase.

dbcve · scoped
Upgrade available Upgrade to 4.10 / 4.15 / 4.20 or later
Fixed in 4.104.154.20
Interim mitigation

The kernel fix requires properly releasing the temporary block_manager in the error path of dm_cache_metadata_abort. Users can mitigate exposure by avoiding table reload operations on read-only cache metadata and monitoring for kmemleak warnings in kernel logs.

Recommended fix High confidence

Upgrade to Linux kernel 4.10, 4.15, 4.20, or 5.5 (or later stable releases within each respective branch)

  1. Identify the current running kernel version using `uname -r`
  2. Compare the current version against the affected ranges: 4.9.337 to <4.10, 4.14.303 to <4.15, 4.19.270 to <4.20, or 5.4.229 to <5.5
  3. If running an affected version, plan for a system upgrade to a fixed release
  4. Schedule a maintenance window for the kernel upgrade
  5. Upgrade the Linux kernel to version 4.10 or later, 4.15 or later, 4.20 or later, or 5.5 or later depending on which branch you are on
  6. Reboot the system to load the new kernel
  7. Verify the fix is applied by checking the kernel version with `uname -r` and monitoring for dm-cache operations using dmsetup
Caveat Kernel upgrades may require rebuild of out-of-tree modules and should be tested in a non-production environment first; ensure compatibility with existing system utilities and hardware drivers

Generated from the published advisory — verify against the referenced sources before acting.

Fix this in Linux Kernel Scoped from the published advisory
  • Consultation2.0 h
  • Implementation4.0 h
  • Testing6.0 h
  • Review / QA2.0 h
14.0 hours of engineering $2,380
Get the upgrade done

An estimate, not a bill — we confirm scope with you before any work starts. Need it this week? Rush from $3,808.

Scan for this in your stack

Free · runs locally
dbcve dependency scanner

Check whether your project pulls in CVE-2026-53060 — or any other known-vulnerable package — straight from your lock files. Free and open source; it runs locally and uploads nothing.

Get it on GitHub Scan in the browser

References Go to the primary sourcePrimary sources — vendor advisories, patches and trackers. Where our summary and a reference disagree, the reference wins.

Primary sources

Practitioner notes

Contributed

Peer-ranked notes from engineers who’ve handled CVE-2026-53060 in production — separate from our analysis above.

No notes yet

Be the first to add a field note for this CVE — a mitigation you’ve verified, a version caveat, or a link to a working fix. Sign in above to contribute.

What this is

A place for practitioners to share what actually worked: a mitigation you’ve tested, a configuration change, a version- or environment-specific caveat, or a link to a verified patch. The most useful notes rise to the top as peers upvote them, so the signal stays high.

What belongs here
  • Verified mitigations, workarounds, and config changes
  • Version or environment caveats, and links to real fixes
  • No weaponised exploit code, or anything meant to cause harm
  • No spam, self-promotion, credentials, or personal data