CVE-2026-53059

What it actually does

This is a Linux kernel device-mapper memory-corruption flaw in the dm log component. A 64-bit region count can be truncated into a 32-bit unsigned integer when creating a device-mapper mirror target with an extremely large target length and small region size. The truncated value causes kernel bitsets such as clean_bits, sync_bits, and recovering_bits to be allocated too small, while later log operations use region indexes from the full, untruncated range. The result is out-of-bounds writes to vmalloc-backed kernel heap memory. The most likely impact is a local kernel crash or reboot; because this is a kernel heap write primitive, privilege escalation or broader kernel compromise may be possible depending on exploitability and hardening, but no public exploit maturity is currently indicated.

Why it matters to the business

Successful exploitation can make a Linux host unstable or unavailable by triggering a kernel crash, which can interrupt workloads, storage services, virtualization platforms, CI systems, or appliances that rely on device-mapper. Exploitation generally requires local administrative capability to create or modify device-mapper targets, so the highest risk is on systems where untrusted users, containers, automation, or compromised service accounts can reach privileged storage-management operations. The current EPSS score is low and it is not listed in CISA KEV, but kernel memory-corruption issues should still be prioritized on multi-user systems, shared infrastructure, and hosts where local privilege boundaries matter.

How an attack unfolds

An attacker first obtains local access to a Linux system with the ability to issue device-mapper control operations, typically root or CAP_SYS_ADMIN-equivalent privileges. They create an oversized device-mapper target, such as a mirror target, whose calculated region count exceeds the 32-bit range while using a small enough region size to trigger truncation. During device-mapper log context creation, the kernel stores the 64-bit result in a 32-bit local variable, causing an undersized allocation for internal synchronization bitmaps. Subsequent mirror/log status or synchronization operations access bits using indexes based on the real, much larger region space, producing out-of-bounds writes in kernel memory. This can corrupt kernel heap state and commonly results in an oops, panic, hang, or reboot; in a more advanced scenario, an attacker may attempt to shape the corruption for privilege escalation.

How to fix it

Upgrade to a Linux kernel version provided by the relevant distribution or vendor that includes the dm log fix for the region_count overflow. The upstream fix widens region_count handling to sector_t and adds an explicit overflow check before assigning the value to the log context. Because no exact fixed package versions were supplied, use vendor advisories for the deployed distribution, including RHEL, Ubuntu, Debian, SUSE, Fedora, Amazon Linux, Oracle Linux, Android-derived kernels, appliance kernels, and cloud-provider kernel channels. After patching, reboot into the fixed kernel and remove or decommission any vulnerable running kernels. If immediate patching is not possible, restrict device-mapper administration to trusted administrators only, remove unnecessary CAP_SYS_ADMIN from containers and services, prevent untrusted users from invoking dmsetup or equivalent storage orchestration tooling, and monitor for creation of unusually large mirror targets. Mitigation should not be considered equivalent to patching because the vulnerable code remains reachable by privileged local actors.

How to confirm the fix worked

Confirm that the running kernel, not merely the installed package, has been updated by checking the active kernel version after reboot and comparing it with the vendor advisory for this issue. Verify that no workloads are still booted into older kernels. Review whether untrusted users, containers, or automation have CAP_SYS_ADMIN, access to /dev/mapper/control, or permission to run dmsetup. On test systems only, defenders may validate exposure by attempting to create a device-mapper mirror configuration with an oversized target and confirming that the fixed kernel rejects it cleanly rather than truncating the region count or crashing. Avoid running proof-of-concept commands on production systems because they may panic the kernel. Also validate that monitoring detects device-mapper table creation, suspicious dmsetup usage, and kernel oops/panic messages involving dm_log or core_in_sync.

Typical attack path

1. Gain local shell, compromised service execution, or administrative access on a Linux host.
2. Obtain the ability to use device-mapper control operations, such as root or CAP_SYS_ADMIN-equivalent privileges.
3. Create a very large device-mapper target length with a small region size so the calculated mirror/log region count exceeds UINT_MAX.
4. Load or activate a vulnerable mirror target configuration that causes region_count truncation during dm log context creation.
5. Trigger device-mapper log operations such as status, synchronization, bit set, bit clear, or bit test operations.
6. Cause out-of-bounds writes in vmalloc-backed kernel memory, leading to kernel crash, reboot, or potentially controlled memory corruption.

How to detect it

To determine whether exploitation or attempted exploitation already occurred, review host audit logs, shell histories, sudo logs, process execution telemetry, EDR events, and kernel logs for device-mapper activity shortly before crashes or reboots. Focus on executions of dmsetup or storage tooling that create mirror targets with extremely large sector counts, especially values around or above 4294967296 regions or target lengths such as 8589934594 sectors. Check auditd for access to /dev/mapper/control, device-mapper ioctls, and executions by unexpected users or service accounts. Review dmesg, journald, syslog, kmsg, crash dumps, and kernel panic records for dm_log, core_in_sync, vmalloc corruption, recursive fault, scheduling while atomic, or udev-worker crash context. In containerized environments, examine container runtime and Kubernetes audit data for containers granted privileged mode, host device access, or CAP_SYS_ADMIN followed by dmsetup or LVM activity. Because the vulnerability may only leave crash artifacts, absence of a clean application log event does not rule out exploitation; correlate device-mapper table creation events with abrupt host reboots, kernel oops messages, and incomplete storage-device setup operations.

• dmsetup create bigzero --table '0 8589934594 zero'
• dmsetup create mymirror --table '0 8589934594 mirror
• 8589934594 mirror core 2 2 nosync
• /dev/mapper/bigzero
• core_in_sync+0x14/0x30 [dm_log]
• BUG: scheduling while atomic
• Fixing recursive fault but reboot is needed
• RIP: 0010:core_in_sync
• CR2: 0000000000000008
• udev-worker
• dm_log
• /dev/mapper/control
• DM_DEV_CREATE
• DM_TABLE_LOAD
• sync_count=1
• 1/4294967297

What your security team should do

• Prioritize patching and rebooting Linux systems where local users, containerized workloads, virtualization tenants, storage automation, or compromised service accounts may reach device-mapper functionality.
• Inventory systems exposing /dev/mapper/control and systems where dmsetup, LVM, multipath, cryptsetup, or storage orchestration tools can be invoked by automation or non-interactive accounts.
• Remove CAP_SYS_ADMIN and broad device access from containers and services unless strictly required; treat these privileges as sufficient to reach this bug.
• Search recent logs for suspicious or failed device-mapper mirror target creation, unusually large sector counts, kernel oopses, and crashes involving dm_log or core_in_sync.
• Ensure kernel live-patching programs, if used, actually include this fix; otherwise schedule a full kernel update and reboot.
• On systems that cannot be patched immediately, restrict dmsetup and device-mapper control access to a small set of trusted administrators and increase monitoring for device-mapper ioctl activity.
• After remediation, confirm the active booted kernel is fixed and remove vulnerable fallback kernels where operationally feasible.