CVE-2026-53064

What it actually does

This is a Linux kernel device-mapper cache bug in passthrough mode. During cache entry invalidation, a concurrent write to the same cached block can cause the bio prison cell acquisition path to fail while leaving the internal mg->cell pointer NULL. The error handling path then attempts to unlock and free that cell unconditionally, causing a NULL pointer dereference in kernel context. The expected technical result is a kernel oops or panic, leading to denial of service. The issue is not described as allowing data theft, authentication bypass, or privilege escalation.

Why it matters to the business

Systems using Linux device-mapper cache in passthrough mode may be crashed by a specific concurrent write pattern, causing service interruption, failed storage operations, node reboots, or workload disruption. The risk is highest for hosts where users, containers, jobs, or storage automation can write to affected cached block devices or manage device-mapper configuration. EPSS is low, it is not listed in CISA KEV, and no public exploit maturity is reported, so broad internet-scale exploitation is unlikely; however, storage-layer kernel crashes can still have significant operational impact on affected Linux servers.

How an attack unfolds

An attacker first needs access to a Linux system using an affected kernel with dm-cache configured, especially a cache target reloaded into passthrough mode. If the attacker can create or manipulate device-mapper cache devices, they can reproduce the vulnerable state directly; if the cache device already exists and is writable, they may only need write access to the exposed block device or filesystem backed by it. The attacker causes a cache block to be present, switches or relies on passthrough mode, and then performs concurrent writes to the same cached block. Under the race condition, the dm-cache invalidation path fails to acquire the expected cell, leaves the pointer NULL, and later dereferences it during cleanup. This produces a kernel NULL pointer dereference, typically visible in dmesg or journald with stack frames such as dm_cell_unlock_v2, invalidate_complete, cache_map, and dm_submit_bio, and may crash or reboot the host depending on kernel panic settings.

How to fix it

Apply a Linux kernel update from the operating system or appliance vendor that includes the fix for dm-cache NULL pointer dereference in passthrough-mode invalidation. Where exact fixed package versions are not available, use the latest supported kernel stream containing the upstream change that checks whether mg->cell is valid before unlocking it. Reboot into the fixed kernel after installation. As interim mitigation, avoid using dm-cache passthrough mode on affected kernels where possible, restrict administrative access to dmsetup and block-device management, limit write access to cached block devices to trusted workloads, and avoid exposing affected storage paths to untrusted concurrent write workloads. For high-availability systems, migrate workloads or fail over before patching to reduce downtime risk.

How to confirm the fix worked

Confirm that the running kernel, not just the installed package, is a vendor-fixed build by checking uname -r and the vendor security advisory or changelog for the dm-cache passthrough invalidation fix. On source-based or internally built kernels, verify that the dm-cache invalidate_complete cleanup path checks mg->cell for NULL before calling the cell unlock/free logic. Confirm whether dm-cache is in use with dmsetup ls, dmsetup table, and lsmod or modinfo for dm_cache-related modules. Validate that no cache targets are operating in passthrough mode unless intentionally required. If operationally safe, perform any race-condition reproduction only in an isolated non-production system because successful reproduction may crash the kernel.

Typical attack path

1. Identify or obtain access to a Linux host running an affected kernel with device-mapper cache support.
2. Find or create a dm-cache device using metadata, cache data, and origin devices.
3. Promote at least one data block into the cache by writing through the cache device.
4. Reload or operate the cache target in passthrough mode.
5. Generate concurrent direct writes to the same cached block, for example with multiple writer jobs.
6. Trigger the race in dm-cache invalidation so the kernel attempts to unlock a NULL cell pointer.
7. Cause a kernel oops, panic, reboot, or storage-service disruption.

How to detect it

Review kernel logs from journald, dmesg, syslog, kdump, crash dumps, and centralized log collection for kernel oops or panic events involving dm-cache during concurrent write activity. Key artifacts include NULL pointer dereference messages, KASAN null-ptr-deref reports, and call traces containing dm_cell_unlock_v2, invalidate_complete, map_bio, cache_map, dm_submit_bio, or __submit_bio. Correlate crash times with storage configuration changes such as dmsetup suspend, reload, or resume, cache targets entering passthrough mode, and high-concurrency write tools or workloads such as fio. Because this is a denial-of-service condition rather than a code-execution issue, there may be no persistent attacker-created file or network indicator; evidence is most likely limited to kernel crash logs, device-mapper command history, shell history, audit logs for privileged storage commands, and workload telemetry showing concurrent writes to affected cached devices.

• KASAN: null-ptr-deref
• null-ptr-deref in range [0x0000000000000000-0x0000000000000007]
• BUG: kernel NULL pointer dereference
• Oops: 0000
• RIP: 0010:dm_cell_unlock_v2
• dm_cell_unlock_v2+
• invalidate_complete+
• map_bio+
• cache_map+
• __map_bio+
• dm_submit_bio+
• __submit_bio+
• dm cache
• metadata2 passthrough
• dmsetup reload cache
• dmsetup suspend cache
• dmsetup resume cache
• fio --filename=/dev/mapper/cache
• --rw=randwrite
• --numjobs=2

What your security team should do

• Prioritize patching Linux systems that use device-mapper cache, storage virtualization, local block-device caching, or appliance kernels built on affected Linux versions.
• Inventory hosts for dm-cache usage with dmsetup and kernel module checks, then identify any cache targets using passthrough mode.
• Restrict dmsetup, CAP_SYS_ADMIN, raw block-device access, and storage-management privileges to trusted administrators and tightly controlled automation.
• Schedule reboots into fixed kernels after package installation; kernel fixes are not effective until the fixed kernel is running.
• Monitor kernel logs for NULL pointer dereference, KASAN, oops, panic, and stack traces involving dm-cache functions.
• Treat unexpected crashes on storage-heavy Linux hosts as potentially related until kernel logs and dm-cache configuration are reviewed.
• If passthrough mode is required before patching, reduce exposure by limiting concurrent untrusted write workloads to affected cached devices.