CVE-2026-53060: Linux Kernel Use-After-Free Vulnerability

CVE-2026-53060 Overview

CVE-2026-53060 is a memory leak vulnerability in the Linux kernel's device-mapper (dm) cache metadata subsystem. The flaw resides in dm_cache_metadata_abort, where a temporary block_manager object allocated outside the root_lock is not released when the function fails to acquire the lock because the block_manager is read-only. Repeated invocations of the abort path leak kernel memory on each call.

The issue is reproducible by reloading a dm-cache table while the metadata is in read-only mode, which causes dm_cache_metadata_abort to execute multiple times. The vulnerability was resolved in the upstream Linux kernel through multiple stable-tree backports.

Critical Impact
Repeated dm-cache metadata abort operations leak kernel slab memory, degrading host stability over time on systems using dm-cache with degraded or faulty metadata devices.

Affected Products

Linux kernel (device-mapper cache target)
Linux distributions shipping vulnerable dm-cache code prior to the stable backports
Storage stacks built on dm-cache with metadata devices subject to I/O errors

Discovery Timeline

2026-06-24 - CVE-2026-53060 published to NVD
2026-06-24 - Last updated in NVD database

Technical Details for CVE-2026-53060

Vulnerability Analysis

The vulnerability stems from improper resource management in dm_cache_metadata_abort within the Linux kernel's dm-cache target. The function allocates a temporary block_manager via dm_block_manager_create before attempting to take the root_lock. When the existing block_manager is read-only, the function bails out without freeing the newly allocated object, leaving a 16-byte allocation orphaned in the slab cache.

A reliable trigger is the table-preload scenario referenced in commit 9b1cc9f251af. After dm-cache enters read-only metadata mode following a metadata I/O failure, reloading the same table and resuming it causes cache_preresume to call metadata_operation_failed, which invokes dm_cache_metadata_abort more than once. Each retry leaks another block_manager allocation.

The kmemleak trace published with the fix shows the leak path: kmemleak_alloc → __kmalloc_cache_noprof → dm_block_manager_create → dm_cache_metadata_abort → metadata_operation_failed → cache_preresume → dm_table_resume_targets → __dm_resume → dm_resume.

Root Cause

The root cause is a missing cleanup path on an early-exit branch. The temporary block_manager is created outside the lock as an optimization, but the read-only check inside the lock returns without calling the corresponding destroy routine. Concurrent metadata_operation_failed calls racing on cache-mode updates can produce the same condition.

Attack Vector

The vulnerability is triggered locally by privileged operations that manipulate dm-cache devices, such as dmsetup reload and dmsetup resume against a cache whose metadata device returns I/O errors. The published reproducer constructs a cache with faulty trailing metadata blocks, forces a failed commit through fio writes, and then preloads and resumes the table to invoke the leaking path. The reproducer requires CAP_SYS_ADMIN and is therefore a stability and resource-exhaustion issue rather than a remote attack surface. See the upstream commits in the kernel.org stable tree for technical details.

Detection Methods for CVE-2026-53060

Indicators of Compromise

Kernel kmemleak reports referencing dm_block_manager_create followed by dm_cache_metadata_abort and metadata_operation_failed in the backtrace.
Recurring dm-cache messages indicating metadata transitioned to read-only mode followed by repeated table resume operations.
Gradual growth of unaccounted slab memory on hosts running dm-cache workloads with unstable metadata devices.

Detection Strategies

Enable CONFIG_DEBUG_KMEMLEAK on test or canary kernels and scan /sys/kernel/debug/kmemleak for the dm-cache backtrace shown in the advisory.
Audit kernel logs (dmesg, journalctl -k) for sequences of dm-cache metadata I/O errors paired with dmsetup reload/resume activity.
Track meminfo Slab and slabtop deltas on hosts that exercise dm-cache failover paths to flag abnormal growth.

Monitoring Recommendations

Alert on dm-cache metadata mode transitions to read-only in production storage hosts.
Monitor kernel slab consumption trends and correlate spikes with device-mapper administrative events.
Aggregate dmsetup command execution from auditd into a central log store for forensic review.

How to Mitigate CVE-2026-53060

Immediate Actions Required

Apply the upstream stable kernel update that includes the dm cache metadata: fix memory leak on metadata abort retry commit on all affected hosts.
Inventory systems using dm-cache and prioritize patching nodes whose metadata devices have shown I/O errors.
Reboot patched hosts to clear any leaked allocations accumulated before the fix was applied.

Patch Information

The fix is published in the upstream Linux stable tree across multiple branches. Reference the commits: 044ca491d408, 14f60e957f34, 15c30997dca6, 322a3b70368d, 4311ca59a189, 6b97cc7a4290, b0bd35535bdb, and d1a79620c419. Consume the fix through your distribution's kernel security update channel once the backport lands.

Workarounds

Avoid reloading dm-cache tables while the cache metadata is in read-only mode until the patch is deployed.
Replace or remediate failing metadata devices promptly so dm-cache does not enter the read-only path that triggers the leak.
Schedule maintenance reboots to reclaim leaked slab memory on long-running hosts that cannot be patched immediately.

bash

# Check current kernel and dm-cache status
uname -r
dmsetup status --target cache
dmsetup info cache

# Inspect for memory leak traces (requires CONFIG_DEBUG_KMEMLEAK)
echo scan > /sys/kernel/debug/kmemleak
cat /sys/kernel/debug/kmemleak | grep -A 10 dm_cache_metadata_abort