CVE-2026-53061

What it actually does

This vulnerability is a race/ordering flaw in the Linux kernel device-mapper cache target. When a dm-cache device is reloaded into passthrough mode using table preloading, the kernel previously checked whether cached mappings were dirty during table creation instead of at the pre-resume stage. Because metadata updates can still occur between preload and resume, dirty cache blocks may be accepted into passthrough mode. Passthrough mode is intended to avoid using dirty cached data, so allowing dirty mappings there can cause writes to be bypassed or mishandled, resulting in block-level data inconsistency or data loss. Exploitation requires the ability to manipulate device-mapper/LVM cache configuration, which generally implies root or equivalent local administrative privileges.

Why it matters to the business

Systems using Linux device-mapper cache, particularly LVM cache in writeback mode, may suffer silent data corruption or data loss during cache mode transitions. The most likely operational impact is loss of filesystem, database, virtual machine, or application data stored on affected cached volumes. Because this is not known to be remotely exploitable and has low EPSS with no known KEV listing or mature public exploit activity, urgency is highest for storage-heavy Linux servers, virtualization hosts, database hosts, and systems where administrators or automation perform LVM/dm-cache reloads or mode changes.

How an attack unfolds

An attacker who already has local root-level control, or the ability to run privileged storage management commands, prepares a dm-cache or LVM cache volume in writeback mode and creates dirty cache mappings. They then preload an inactive device-mapper table that switches the cache target into passthrough mode. Before the table is resumed, writes or metadata changes occur that leave dirty mappings present. Due to the flawed timing of the dirty-mapping check, the kernel may allow the inactive passthrough table to become active even though dirty cache mappings exist. Once active, the cache can operate in an invalid state and data that should have been flushed or protected may be lost or become inconsistent. There are no public indications that named threat actors are exploiting this issue, and it is more likely to be abused by a privileged insider, malicious local administrator, or triggered accidentally by automation than used as an initial compromise vector.

How to fix it

Upgrade to a Linux kernel version that includes the upstream fix moving the dirty-mapping validation for dm-cache passthrough mode to the pre-resume phase. Because no specific fixed package versions were provided, use the latest vendor-supported kernel for the affected distribution and confirm that the vendor advisory includes the dm-cache fix for this issue. Reboot into the fixed kernel after installation. As a mitigation until patching is complete, avoid switching dm-cache/LVM cache volumes into passthrough mode while dirty mappings may exist; flush or clean cached volumes before cache mode changes; avoid risky automated table preload/reload workflows; restrict use of dmsetup, lvm, and privileged storage automation to trusted administrators; and ensure current backups exist before any cache mode transition.

How to confirm the fix worked

Confirm the running kernel has been updated to a vendor build containing the fix, not merely that the package is installed. Validate with commands such as uname -r and the distribution package manager, then compare against the vendor advisory for this issue. Review LVM/dm-cache configurations for cached volumes using lvs -a -o +cache_mode,cache_policy,devices or dmsetup table/status. For functional validation in a non-production test system, verify that attempting to activate passthrough mode while dirty mappings exist is rejected or handled safely after the fix. Confirm affected hosts have been rebooted into the patched kernel and that no cached volumes remain in an unexpected passthrough/writeback transition state.

Typical attack path

1. Obtain root, CAP_SYS_ADMIN, or equivalent administrative control over a Linux system that uses dm-cache or LVM cache.
2. Identify or create a device-mapper cache target using writeback caching.
3. Generate dirty cache mappings by writing to the cached device while migration or flushing behavior leaves dirty blocks present.
4. Preload a replacement device-mapper table that switches the cache target to passthrough mode.
5. Trigger additional writes or metadata updates before the preloaded table is resumed.
6. Resume the inactive table, causing passthrough mode to activate despite dirty mappings.
7. Cause or observe block-level inconsistency, filesystem corruption, application errors, or data loss on the cached volume.

How to detect it

There is no reliable network IOC for this vulnerability because exploitation is local and involves privileged storage-management operations. To assess possible prior exploitation or accidental triggering, review Linux audit logs, shell history, sudo logs, systemd journal, kernel logs, and LVM/device-mapper logs for dm-cache reloads, passthrough mode changes, and suspicious use of dmsetup or LVM commands. Focus on sequences where writeback cached volumes were reloaded or resumed into passthrough mode, followed by filesystem errors, I/O errors, application corruption, database recovery events, unexpected read-only remounts, or backup integrity failures. Useful log sources include /var/log/audit/audit.log, /var/log/auth.log or /var/log/secure, /var/log/syslog, /var/log/messages, journalctl -k, journalctl for lvm2 services, root shell histories, and EDR command-line telemetry. Look for commands that create or reload cache targets, especially with parameters such as cache, writeback, passthrough, migration_threshold, dmsetup reload, and dmsetup resume. Because successful exploitation primarily manifests as data inconsistency, detection should combine command telemetry with storage and application integrity checks rather than relying on a single indicator.

• dmsetup reload
• dmsetup resume
• dmsetup create cache
• cache
• writeback
• passthrough
• migration_threshold 0
• lvconvert --type cache
• lvconvert --cachemode passthrough
• lvconvert --cachemode writeback
• lvs -a -o +cache_mode
• device-mapper: cache
• dm-cache
• cache metadata
• EXT4-fs error
• XFS corruption
• Buffer I/O error
• blk_update_request: I/O error
• Remounting filesystem read-only

What your security team should do

• Prioritize patching Linux systems that use LVM cache or dm-cache for databases, virtual machine storage, file servers, or other critical persistent data.
• Inventory use of dm-cache and LVM cache across Linux fleets; systems not using device-mapper cache are unlikely to be exposed to the vulnerable code path.
• Apply vendor kernel updates and reboot into the fixed kernel; verify the running kernel version after reboot.
• Before patching, avoid dm-cache passthrough mode transitions unless dirty data has been flushed and backups are verified.
• Restrict root-level storage administration access and monitor use of dmsetup, lvconvert, lvs, lvchange, and other LVM/device-mapper tooling.
• Review storage automation, maintenance scripts, and orchestration jobs for workflows that preload or reload dm-cache tables.
• Increase monitoring for filesystem errors, I/O errors, unexpected read-only remounts, application data corruption, and dm-cache metadata warnings on systems using cached volumes.
• Ensure recent, restorable backups exist for systems using writeback caching before performing cache configuration changes.