CVE-2026-53265

What it actually does

This is a race condition in the Linux kernel device-mapper cache SMQ policy. The vulnerable code checks whether a cache entry is allocated before acquiring the lock that protects destructive invalidation operations. Two concurrent invalidation paths can both observe the same entry as allocated, after which one thread removes and frees it while the other continues using the stale state. This can corrupt SMQ queues or hash-table state, trigger a double-free-style consistency check, and potentially cause kernel warnings, crashes, or broader memory corruption in systems using dm-cache with the SMQ policy.

Why it matters to the business

Systems that rely on Linux device-mapper cache may experience storage instability, kernel crashes, or service outages if the race is triggered. Because the issue is in kernel storage code, impact can include interrupted applications, degraded storage reliability, and unplanned downtime. The available intelligence indicates low exploitation likelihood, no known public exploit maturity, no CISA KEV listing, and no known ransomware use, so this should generally be prioritized as a stability and hardening update rather than an emergency internet-facing exposure.

How an attack unfolds

An attacker would need a path to influence or trigger concurrent invalidation activity against a dm-cache device using the SMQ cache policy. By causing overlapping cache-block invalidation operations, two execution contexts can race: both see the same cache entry as allocated, one acquires the SMQ lock and frees the entry, and the second later acquires the lock and performs destructive operations based on stale state. The most likely outcome is kernel data-structure corruption or a crash, resulting in denial of service. Exploitation for privilege escalation is not established from the available information and would depend on precise kernel version, configuration, memory layout, and attacker ability to shape the race.

How to fix it

Upgrade to a Linux kernel version that includes the fix for the dm-cache SMQ invalidation locking issue. The corrected behavior moves the allocation check under the same lock that protects destructive invalidation operations. If vendor-specific fixed versions are not available, apply the latest stable kernel update from the operating system or appliance vendor that references this CVE or the upstream fix for 'dm cache policy smq: check allocation under invalidate lock'. As a temporary mitigation, reduce exposure by avoiding use of dm-cache with the SMQ policy on untrusted multi-user systems, limiting local administrative access, and avoiding high-risk cache invalidation operations until patched. Where operationally feasible, migrate affected workloads away from vulnerable dm-cache configurations or disable dm-cache on systems where storage caching is not required.

How to confirm the fix worked

Confirm the running kernel package includes the vendor fix for this CVE or the upstream patch that moves the SMQ allocation check under mq->lock. Inventory systems for dm-cache usage by checking device-mapper configuration and whether cache targets are active. Validate that patched systems have been rebooted into the updated kernel, not merely had the package installed. Review kernel changelogs or vendor advisories for the dm-cache SMQ fix. After patching, run representative storage-cache workloads and monitor kernel logs for device-mapper cache warnings, BUG splats, lockdep warnings, or crashes related to dm-cache or smq invalidation.

Typical attack path

1. Identify a Linux system using device-mapper cache with the SMQ cache policy enabled.
2. Obtain local access or another execution path capable of generating relevant cache invalidation activity.
3. Create high-concurrency cache invalidation, discard, resize, or cache-management activity against the affected dm-cache device.
4. Trigger the check-then-act race where two invalidators operate on the same cache entry.
5. Cause SMQ queue or hash-table corruption, double-free detection, kernel warning, or kernel crash.
6. Leverage the resulting instability primarily as a denial-of-service condition.

How to detect it

To determine whether the issue may have been triggered, review kernel and system logs from affected Linux hosts for crashes, BUG splats, WARN messages, lockdep reports, or oops traces involving device-mapper cache, dm-cache, smq, cache invalidation, queue corruption, hash-table corruption, or double-free-like allocation checks. Useful log sources include journalctl kernel logs, /var/log/kern.log, /var/log/messages, /var/log/syslog, crash dump records, kdump/vmcore analysis, and hypervisor or out-of-band management reset events. Correlate suspicious events with high-volume storage activity, cache invalidation, discard/TRIM operations, device-mapper table reloads, cache target changes, or maintenance jobs. There are no known public exploit artifacts, network indicators, or threat-actor-specific indicators for this vulnerability; evidence is expected to appear as local kernel instability rather than distinctive malware or network traffic.

• dm cache policy smq
• smq_invalidate_mapping
• free_entry
• device-mapper: cache
• dm-cache
• cache policy smq
• BUG: kernel NULL pointer dereference
• kernel BUG
• WARNING: CPU
• general protection fault
• Unable to handle kernel paging request
• Oops:
• Call Trace:
• invalid opcode
• double free
• corrupted list
• list_del corruption
• hash table corruption
• allocation check
• dm_cache_policy_smq

What your security team should do

• Inventory Linux hosts using device-mapper cache, especially systems with active dm-cache targets and the SMQ policy.
• Prioritize patching storage servers, virtualization hosts, database hosts, and other systems where a kernel crash would cause high operational impact.
• Upgrade to the latest vendor-supported kernel containing the dm-cache SMQ locking fix and reboot into the fixed kernel.
• Restrict local shell, container, and administrative access on systems using dm-cache until remediation is complete.
• Monitor kernel logs for device-mapper cache errors, kernel BUG messages, general protection faults, or crashes involving dm-cache SMQ code.
• Because EPSS is low and there is no KEV listing or known ransomware association, treat this as a scheduled-but-important kernel maintenance item unless affected systems are highly critical or exposed to untrusted local users.