CVE-2026-53060

What it actually does

This is a Linux kernel device-mapper cache metadata memory leak in the dm-cache metadata abort path. When dm_cache_metadata_abort() fails to acquire root_lock because the block manager is read-only, a temporary block_manager allocated earlier is not released. Repeated abort/retry paths, such as dm-cache table reload/resume operations while cache metadata is read-only or failing, can leak small kernel allocations over time. The practical technical outcome is kernel memory exhaustion and denial of service, especially on systems using dm-cache with faulty, read-only, or erroring metadata devices. Exploitation appears to require local administrative capability to manipulate device-mapper tables or an equivalent privileged storage-management path; no public exploit maturity is indicated and EPSS is very low.

Why it matters to the business

Systems that use Linux dm-cache for storage acceleration can become unstable or unavailable if kernel memory is gradually leaked through repeated cache metadata abort operations. The most likely operational impact is degradation or outage of hosts, storage services, virtualization platforms, or appliances that depend on affected dm-cache configurations. Because the issue is not in CISA KEV, is not known to be used in ransomware, and has a low EPSS score, it should generally be prioritized behind remotely exploitable or actively exploited issues, but patched during normal kernel maintenance for any environment using dm-cache or exposing privileged storage automation.

How an attack unfolds

An attacker must first have local root privileges, CAP_SYS_ADMIN, or control over a privileged component that can issue device-mapper operations. They create or manipulate a dm-cache device so that its metadata path enters a read-only or failing state, then repeatedly suspend, reload, and resume the cache table or otherwise trigger concurrent metadata_operation_failed paths. During preresume, dm-cache attempts to abort metadata work, creates a temporary block manager, then fails in the read-only/root_lock path without freeing that allocation. Repeating the sequence leaks kernel memory. Over time, the system may experience memory pressure, degraded I/O behavior, process failures, or a host-level denial of service.

How to fix it

Upgrade to a Linux kernel version, distribution kernel package, or appliance firmware that includes the upstream dm-cache metadata fix for the abort retry memory leak. Because exact fixed package versions were not provided, use vendor advisories for the specific distribution or product and confirm the fix is included in the device-mapper cache metadata code. Where immediate patching is not possible, reduce exposure by limiting dmsetup and device-mapper administration to trusted administrators only, disabling unnecessary dm-cache deployments, avoiding automated table reload/resume workflows on unhealthy dm-cache devices, monitoring metadata device health, and isolating workloads that can influence privileged storage orchestration.

How to confirm the fix worked

Confirm the running kernel package contains the vendor fix for the dm-cache metadata abort retry leak. Inventory systems for dm-cache usage with device-mapper tools, such as dmsetup ls, dmsetup table, and dmsetup status, and prioritize hosts with active cache targets. After patching, reboot into the fixed kernel if required by the distribution. In test environments only, validate that repeated dm-cache suspend/reload/resume operations against read-only or failing metadata no longer produce kmemleak reports referencing dm_block_manager_create(), dm_cache_metadata_abort(), metadata_operation_failed(), or cache_preresume(). In production, validate indirectly by confirming the fixed kernel is active and monitoring for absence of recurring dm-cache metadata failures and unexplained kernel memory growth.

Typical attack path

1. Obtain local administrative privileges or equivalent capability to manage Linux device-mapper targets.
2. Identify or create a dm-cache device using separate metadata, cache data, and origin devices.
3. Force dm-cache metadata into an erroring or read-only state, for example by using faulty metadata blocks or an error-backed metadata mapping.
4. Trigger metadata activity by writing through the cache device.
5. Reload the same or equivalent dm-cache table while metadata is in the problematic state.
6. Suspend and resume the dm-cache device to drive the cache preresume and metadata abort path.
7. Repeat the operation to leak kernel memory until service degradation or denial of service occurs.

How to detect it

To determine whether this was already triggered, review kernel logs, audit logs, command history, and storage-management automation logs for repeated dm-cache suspend, reload, and resume operations combined with cache metadata errors or read-only metadata state. Useful sources include journald, /var/log/kern.log, /var/log/messages, auditd execve records, sudo logs, shell histories for administrative users, EDR process telemetry, and any storage-orchestration logs that invoke dmsetup. Look for kmemleak reports or kernel traces containing dm_block_manager_create, dm_cache_metadata_abort, metadata_operation_failed, cache_preresume, and dm_table_resume_targets. Also investigate unexplained kernel memory growth on systems with active dm-cache targets, especially when correlated with repeated dmsetup activity. Because this is a memory leak rather than a code-execution vulnerability, there may be no durable file artifact; evidence is most likely in kernel diagnostics, process execution telemetry, and operational symptoms such as memory pressure or host instability.

• dm_cache_metadata_abort
• dm_block_manager_create
• metadata_operation_failed
• cache_preresume
• dm_table_resume_targets
• __dm_resume
• dm_resume
• unreferenced object
• comm "dmsetup"
• dmsetup reload cache
• dmsetup suspend cache
• dmsetup resume cache
• dmsetup create cache
• dmsetup create cmeta
• dmsetup create cdata
• dmsetup create corig
• /dev/mapper/cache
• /dev/mapper/cmeta
• /dev/mapper/cdata
• /dev/mapper/corig
• cache /dev/mapper/cmeta /dev/mapper/cdata /dev/mapper/corig
• kmemleak_alloc

What your security team should do

• Inventory Linux systems using device-mapper cache targets and prioritize those for kernel updates.
• Apply vendor kernel or appliance updates that include the dm-cache metadata memory leak fix, then reboot where required.
• Restrict dmsetup, CAP_SYS_ADMIN, and storage orchestration privileges to trusted administrators and hardened automation accounts.
• Monitor systems using dm-cache for metadata I/O errors, read-only metadata transitions, repeated suspend/resume/reload operations, and unexplained kernel memory growth.
• Review audit and shell history logs for unusual dmsetup reload, suspend, resume, or cache table manipulation by privileged users.
• If dm-cache is not required, consider disabling or replacing it to reduce storage-layer attack surface.
• Treat suspicious repeated device-mapper manipulation as potential local privilege misuse, even though this issue requires elevated access and is not known to be actively exploited.