CVE-2026-53062

What it actually does

This is a race condition in the Linux kernel device-mapper cache target, specifically the smq cache policy when invalidating cache blocks in passthrough mode. Multiple worker threads can call the invalidate_mapping operation concurrently without adequate locking, leading to unsynchronized updates to internal counters and possible use-after-free of cache policy data structures during concurrent writes. The practical technical outcomes are incorrect cache accounting, kernel memory corruption, kernel warnings or crashes, and potential data integrity issues on systems using dm-cache in passthrough mode. Exploitation requires local ability to configure or drive I/O through an affected device-mapper cache setup, typically requiring root or equivalent storage administration privileges.

Why it matters to the business

Systems using Linux device-mapper cache in passthrough mode may experience storage instability, corrupted cache state, kernel crashes, or service outages under concurrent write workloads. The risk is most relevant to Linux servers, virtualization hosts, storage appliances, and embedded platforms that use dm-cache for block-device caching. The current EPSS is very low and there is no known CISA KEV listing or ransomware association, so broad opportunistic exploitation is unlikely; however, the operational impact can still be serious where affected storage configurations are in production.

How an attack unfolds

An attacker first needs local access with sufficient privileges to create, reload, or interact with a device-mapper cache target, or access to an already configured affected dm-cache device in passthrough mode. They then cause concurrent write I/O patterns against the cached block device so that multiple kernel workers invalidate cache mappings at the same time. Because the smq policy invalidation path lacks proper locking, the workers can race while updating shared cache policy state. This can produce inconsistent cache block counts, corrupt internal structures, or trigger a use-after-free condition. Depending on timing and kernel hardening, the visible result may be incorrect device-mapper cache status, I/O errors, kernel oops/panic, or potential memory-corruption side effects. No public exploit maturity is indicated, and exploitation appears configuration-dependent rather than remotely reachable.

How to fix it

Apply the vendor-provided Linux kernel update that includes the fix adding appropriate locking around smq invalidate_mapping operations in dm-cache passthrough mode. Because no fixed package versions were provided in the input, use your Linux distribution, kernel vendor, or appliance vendor advisory to identify the corrected kernel build. After patching, reboot into the updated kernel unless live patching is explicitly supported and confirmed to cover this device-mapper cache code path. As a temporary mitigation, avoid using dm-cache passthrough mode with the smq policy on unpatched kernels, avoid reloading cache targets into passthrough mode during production use, and restrict local storage administration privileges such as root and CAP_SYS_ADMIN. Where feasible, reduce concurrent write workloads against affected passthrough cache devices until patched.

How to confirm the fix worked

Confirm the running kernel version matches a vendor build that contains the dm-cache smq locking fix for this issue, not merely that the package is installed. Inventory active device-mapper cache targets with dmsetup and verify whether any use passthrough mode with the smq policy. On patched test systems, reproduce a representative concurrent-write workload against a non-production dm-cache passthrough device and confirm cache accounting remains consistent and no kernel warnings, KASAN reports, I/O errors, or oops events appear. Review booted kernel version with uname and package manager tooling, and verify that hosts requiring reboot after kernel update have actually been restarted.

Typical attack path

1. Gain local access to a Linux system with privileges to administer block devices or access a vulnerable dm-cache configuration.
2. Identify or create a device-mapper cache target using the smq policy.
3. Switch or operate the cache target in passthrough mode.
4. Generate concurrent write workloads against the cache device using multiple jobs or threads with I/O aligned to cache block sizes.
5. Trigger simultaneous cache block invalidation from multiple workers.
6. Cause cache accounting inconsistencies, memory corruption, use-after-free behavior, or a kernel crash.

How to detect it

This issue is not associated with a known remote exploit pattern, so detection should focus on evidence of attempted triggering or resulting kernel instability on systems using dm-cache. Review kernel logs, system journals, crash dumps, pstore records, kdump/vmcore artifacts, and storage monitoring for device-mapper cache warnings, kernel oops or panic events, KASAN/KFENCE use-after-free reports, and I/O errors occurring during or shortly after concurrent write workloads. Look for administrative activity that creates, reloads, suspends, resumes, or switches device-mapper cache targets into passthrough mode, especially followed by fio-like high-concurrency random write tests. Useful log sources include journalctl -k, /var/log/kern.log, /var/log/messages, auditd logs for dmsetup execution, shell history where available, and crash dump analysis showing call traces through dm-cache smq invalidation routines.

• smq_invalidate_mapping
• invalidate_mapping
• device-mapper: cache
• dm-cache
• passthrough smq
• metadata2 passthrough smq
• BUG: KASAN: use-after-free
• BUG: kernel NULL pointer dereference
• kernel BUG
• Oops:
• Kernel panic
• dmsetup suspend
• dmsetup reload
• dmsetup resume
• dmsetup status cache
• fio --filename=/dev/mapper/cache
• fio --rw=randwrite
• /dev/mapper/cache
• /var/crash
• /sys/fs/pstore

What your security team should do

• Prioritize patching Linux systems that use device-mapper cache, storage caching, virtualization storage backends, or appliance-style block storage configurations.
• Inventory dm-cache usage across Linux fleets, focusing on cache targets using passthrough mode and the smq policy.
• Restrict access to dmsetup, block-device administration, root shells, and CAP_SYS_ADMIN-capable containers or workloads.
• Monitor kernel logs for device-mapper cache errors, KASAN use-after-free reports, kernel oops events, panics, and unexpected storage I/O errors.
• Schedule maintenance windows for kernel updates and required reboots on affected storage-heavy systems.
• If patching must be delayed, avoid passthrough-mode dm-cache configurations and limit high-concurrency write workloads on affected devices.
• Treat crashes or kernel memory-corruption reports involving dm-cache or smq invalidation as potentially security-relevant, even if they appear workload-induced.