CVE-2026-53060: Linux dm-cache Metadata Memory Leak Vulnerability

Technical summary

The vulnerability exists in dm_cache_metadata_abort() within the Linux kernel's device mapper cache metadata layer. When the function cannot acquire the root_lock due to a read-only block_manager state, a temporary block_manager object created prior to the lock acquisition attempt is not deallocated. The leak manifests through repeated calls to dm_cache_metadata_abort, particularly when triggered by the cache preresume path during table reloads. The issue is classified as CWE-401 (Missing Release of Memory after Effective Lifetime) and can occur both through the table preload scenario (which lacks dm-cache table preload support as noted in commit 9b1cc9f251af) and through concurrent metadata_operation_failed calls arising from cache mode synchronization races.

Business impact

While individual leaks are small (16 bytes per occurrence in the reported case), repeated cache device reloads or metadata errors can cause gradual memory exhaustion on systems hosting dm-cache volumes. This is particularly concerning for persistent storage arrays, containerized environments with dynamic volume management, or systems running automated cache device recovery procedures. The impact is amplified in scenarios with frequent cache table updates or transient storage errors that trigger repeated metadata abort cycles.

Affected systems

The vulnerability affects Linux kernel systems running device mapper cache (dm-cache) with versions prior to the patch. Affected systems include those using dm-cache for write-through or write-back caching of storage devices, particularly in enterprise storage, virtualization, and container environments. The issue requires local access and the ability to manipulate dm-cache device tables, making it relevant primarily to system administrators and privileged container orchestration systems.

Exploitability

Exploitation requires local system access and the ability to create or reload dm-cache device tables (typically requiring root or CAP_SYS_ADMIN privileges). The vulnerability is not exploitable for privilege escalation or data exfiltration; its impact is strictly denial-of-service through memory exhaustion. An attacker must trigger specific conditions—metadata read-only state combined with table preload or concurrent metadata failures—making opportunistic remote exploitation unlikely. However, the condition can be reliably reproduced through intentional table manipulations, as demonstrated in the CVE description.

Remediation

Apply the Linux kernel patch that fixes dm_cache_metadata_abort to properly release the temporary block_manager object when lock acquisition fails. Verify the patch version against the vendor advisory for your specific kernel distribution. Until patching, mitigate by minimizing cache device table reloads, implementing monitoring for cache metadata errors, and avoiding scenarios where read-only metadata states occur concurrently with table preload operations.

Patch guidance

Obtain and apply the kernel patch addressing the block_manager leak in dm_cache_metadata_abort. Verify patch availability and version numbers directly from your Linux distribution vendor or the upstream kernel project. Standard practices apply: test patches in a non-production environment first, coordinate downtime for kernel updates, and monitor system stability post-patch. Distributions providing kernel updates through standard package management (yum, apt, etc.) should consume fixes through those channels.

Detection guidance

Monitor kernel memory usage patterns on systems running dm-cache, particularly around cache device reload and suspension events. Use kmemleak (CONFIG_DEBUG_KMEMLEAK) in test or development environments to identify the signature leak pattern shown in the CVE (unreferenced 16-byte allocations in dm_block_manager_create called from dm_cache_metadata_abort). In production, track dm-cache device status and metadata error rates using device mapper statistics; repeated metadata failures coupled with growing kernel memory consumption warrant investigation. Audit logs of dmsetup commands can identify table reload operations preceding memory anomalies.

Why prioritize this

Despite a CVSS score of 5.5 (Medium), this vulnerability warrants timely remediation because memory exhaustion is a persistent denial-of-service vector in production storage environments. The leak is deterministic and reproducible, not speculative. Patching is straightforward and carries minimal risk. Systems with high cache device churn, automated storage orchestration, or known transient metadata errors should prioritize patching. The vulnerability is not in the CISA KEV catalog, indicating lower active exploitation, but this reflects its narrow attack surface rather than lack of importance in vulnerable deployments.

Risk score, explained

The CVSS 3.1 score of 5.5 (Medium) reflects availability impact (denial of service through memory exhaustion) with low complexity and low privilege requirements. The score does not account for the operational context of storage systems, where availability directly impacts business continuity. In environments where cache devices are mission-critical, the effective risk is higher. The vulnerability does not enable confidentiality or integrity violations, nor does it allow privilege escalation, tempering the overall severity. The lack of KEV inclusion reflects that this is not currently being weaponized in the wild, but organizations running affected workloads should not use KEV status as a deferral reason.

Frequently asked questions