CVE-2026-53063

What it actually does

This is a Linux kernel device-mapper cache flaw in passthrough mode. When a cache invalidation races with or precedes a write-hit bio, the kernel can prepare the remap for the overwrite operation but then drop the bio without submitting it to the origin device. The affected write never completes, causing processes waiting on that I/O to hang. The practical technical impact is denial of service for workloads using affected dm-cache configurations, especially where writes depend on completion of blocked block-layer I/O.

Why it matters to the business

Systems using Linux device-mapper cache in passthrough mode may experience stalled writes, hung applications, degraded storage availability, or service outages. The risk is most relevant to servers, appliances, virtualization hosts, or storage nodes that rely on dm-cache-backed volumes. This issue is not currently listed in CISA KEV, is not known to be used in ransomware campaigns, has no reported public exploit maturity, and has a low EPSS score, so urgency is primarily driven by whether affected storage configurations are present in production.

How an attack unfolds

An attacker would need a way to influence or generate write activity against a Linux system using an affected dm-cache target in passthrough mode. They would then create I/O patterns that cause writes to hit cached blocks after cache invalidation behavior occurs. Due to the kernel bug, the write bio can be remapped and then dropped instead of being submitted to the cache origin device. The calling process waits indefinitely for I/O completion, which can accumulate into blocked worker threads, hung applications, or wider service unavailability. In most scenarios, exploitation is local or application-mediated rather than a direct unauthenticated network attack; a remote attacker would typically need to reach an application that performs sustained writes to an affected cached volume.

How to fix it

Upgrade the Linux kernel to a vendor-supported version that includes the dm-cache passthrough write-hang fix. Because no explicit fixed package versions were provided, use the relevant Linux distribution, appliance vendor, cloud image, or kernel-stable advisory to identify the first corrected kernel for the deployed branch. After patching, reboot into the fixed kernel if live patching is not available or does not cover this device-mapper change. Where immediate patching is not possible, reduce exposure by avoiding dm-cache passthrough mode on critical volumes, moving critical workloads away from affected cached devices, disabling or reconfiguring dm-cache where operationally safe, and monitoring aggressively for hung I/O conditions.

How to confirm the fix worked

Confirm exposure by checking whether systems run an affected Linux kernel and use device-mapper cache targets in passthrough mode. Validate remediation by confirming the running kernel version is the vendor-fixed build, not merely that the package is installed. Review `dmsetup status`, `dmsetup table`, and distribution-specific storage configuration to identify dm-cache use. Perform controlled write testing against non-production cached volumes after patching and confirm writes complete normally under cache invalidation or cache mode transition scenarios. Also confirm that kernel logs no longer show blocked tasks, hung I/O, or dm-cache-related stack traces during storage stress testing.

Typical attack path

1. Identify or reach a workload backed by Linux device-mapper cache in passthrough mode.
2. Generate sustained or targeted write operations against files or block devices on the cached volume.
3. Trigger cache invalidation/write-hit sequencing that exercises the vulnerable dm-cache path.
4. Cause affected write bios to be dropped without completion.
5. Induce hung I/O, blocked processes, application stalls, or service degradation.

How to detect it

To assess prior exploitation or triggering, review kernel logs, system journals, hypervisor or appliance logs, and monitoring data for signs of hung block I/O on dm-cache-backed volumes. Useful sources include `/var/log/kern.log`, `/var/log/messages`, `/var/log/syslog`, `journalctl -k`, crash dumps, kdump/vmcore analysis, storage monitoring alerts, and application logs showing write timeouts or unresponsive storage. Look for repeated hung-task warnings, tasks stuck in uninterruptible sleep, high I/O wait, blocked filesystem or database writer threads, device-mapper cache messages, and stack traces mentioning dm-cache invalidation/write paths. Because this flaw causes a denial-of-service condition rather than a clear compromise artifact, detection should focus on correlating affected kernel versions and dm-cache passthrough mode with unexplained write hangs. There are no known threat actors or public exploit campaigns associated with this issue at this time.

• dm-cache
• cache mode: passthrough
• passthrough
• INFO: task
• blocked for more than
• hung_task_timeout_secs
• task blocked for more than
• D state
• device-mapper: cache
• dm_cache
• invalidate_remove
• invalidate_complete
• overwrite_bio
• bio_io_error
• I/O error
• blk_update_request
• Buffer I/O error

What your security team should do

• Inventory Linux systems using device-mapper cache, prioritizing production storage, virtualization, database, container host, and appliance workloads.
• Determine whether dm-cache passthrough mode is enabled on any critical volumes.
• Prioritize kernel updates for systems where affected dm-cache configurations are present, despite the low EPSS score and absence from KEV.
• Coordinate patching with operations teams because a reboot is commonly required for kernel fixes.
• If patching must be delayed, avoid passthrough mode for critical write-heavy workloads where feasible and increase monitoring for hung tasks and I/O stalls.
• Add temporary detections for kernel hung-task messages, dm-cache stack traces, and abnormal growth in blocked I/O wait.
• Review application availability incidents since publication for unexplained storage stalls on dm-cache-backed systems.