CVE-2026-53059: Linux Kernel Device-Mapper Log Integer Overflow Vulnerability

Technical summary

CVE-2026-53059 involves an integer overflow vulnerability in the Linux kernel's dm_log module, specifically in the create_log_context() function. The region_count variable is declared as a 32-bit unsigned int but is assigned the result of dm_sector_div_up(), which returns a 64-bit sector_t. When device-mapper targets have large ti->len values combined with small region_size parameters, the division exceeds UINT_MAX and truncates upon assignment. This truncated value is used to allocate bitmaps (clean_bits, sync_bits, recovering_bits) that are far smaller than needed. Subsequent log operations (log_set_bit, log_clear_bit, log_test_bit) use untruncated region indices from the full address space, causing out-of-bounds writes to vmalloc-allocated heap memory. The vulnerability can be reproduced with dmsetup commands creating a mirror target with region_count overflow (e.g., 0x100000001 truncated to 1), resulting in kernel crashes in functions like core_in_sync with CR2 faults on kernel heap access.

Business impact

Organizations running Linux systems relying on device-mapper mirroring for storage redundancy face potential service disruption through kernel crashes. Affected deployments include storage servers, virtualization hosts, and cloud infrastructure using dm-mirror for RAID-1 functionality. While exploitation requires local access and elevated privileges, successful attacks can crash the kernel, causing immediate downtime and data access loss until reboot. Systems with large-capacity mirrored volumes are at highest risk, particularly in container orchestration and hypervisor environments where administrative interfaces may be accessible to malicious containers or guest VMs.

Affected systems

The vulnerability affects Linux kernel versions containing the vulnerable create_log_context() code path in the device-mapper log module. Systems are at risk when: (1) device-mapper mirroring (dm-mirror) is configured, (2) mirror targets are created with sufficiently large capacity (e.g., 8TB or larger), (3) region_size parameters are small enough to cause region_count to exceed 32 bits, and (4) local unprivileged or privilege-escalated users can execute dmsetup or equivalent device-mapper control commands. This includes physical Linux servers, virtualization hypervisors (KVM, Xen), and containerized environments where dm-mirror is enabled.

Exploitability

Exploitation requires local system access and sufficient privileges to invoke device-mapper operations (typically CAP_SYS_ADMIN or dmsetup group membership). Attack complexity is low once these prerequisites are met; the vulnerability triggers reliably through standard dmsetup commands without requiring specialized tools or race conditions. Public reproduction steps exist in the CVE description. However, widespread exploitation is limited by the requirement for local access and the need to configure dm-mirror targets with specific capacity parameters. The vulnerability is not actively tracked in CISA's KEV catalog as of the current date.

Remediation

Remediation requires patching the Linux kernel to fix the integer overflow in create_log_context(). The official fix widens region_count from unsigned int to sector_t and adds explicit overflow validation before assignment to lc->region_count, ensuring the value does not exceed the maximum safe value for region operations. Organizations should apply kernel patches from their distribution (Red Hat, Canonical, SUSE, etc.) as they become available. Interim mitigations include: restricting dmsetup access to trusted administrators only (via ACLs or group membership), avoiding configuration of dm-mirror targets with regions exceeding 2^32 sectors (approximately 2TB per region at 512-byte sectors), and monitoring for unexpected kernel panics or scheduling-while-atomic warnings in kernel logs referencing dm_log or core_in_sync.

Patch guidance

Apply the latest kernel security update from your Linux distribution vendor. The fix has been merged into the upstream Linux kernel; verify the patch is present by checking kernel version and release notes. Distributors typically backport this fix to stable and LTS kernel branches. Users should monitor advisories from their vendor (Red Hat Security, Ubuntu Security Notices, SUSE Security Updates, etc.) and schedule kernel updates at the next maintenance window, prioritizing systems that actively use dm-mirror. Reboot is required after kernel update. Test the update in non-production environments first, particularly if dm-mirror is actively configured and in use.

Detection guidance

Monitor kernel logs for the specific crash signature: 'BUG: scheduling while atomic' combined with 'core_in_sync' in the call stack or 'CR2' page fault indicating out-of-bounds kernel heap access. Review dmsetup status output for suspicious values such as sync_count values that are unexpectedly small (e.g., 1) compared to the total region count, which suggests integer truncation. Audit local system access and dmsetup command invocations via auditd or systemd audit logs to identify unauthorized device-mapper reconfiguration. Deploy kernel address sanitizer (KASAN) or similar memory debugging tools in test environments to catch out-of-bounds writes before production deployment.

Why prioritize this

This vulnerability merits HIGH priority (CVSS 7.8) due to the combination of: (1) reliable local exploitability via standard tools with no race conditions, (2) impact severity—kernel panic causes immediate denial of service and potential data loss, (3) prevalence of dm-mirror in production storage and virtualization infrastructure, and (4) the relatively easy trigger conditions once local access is obtained. Organizations running large-capacity mirrored storage should treat this as urgent and plan patching within 30 days. Systems without dm-mirror or with small-capacity mirrors face lower practical risk but should still be included in standard update cycles.

Risk score, explained

The CVSS 3.1 score of 7.8 (HIGH) reflects: Attack Vector Local (AV:L) and Attack Complexity Low (AC:L), as exploitation requires only standard system tools and reliable trigger inputs; Privileges Required (PR:L), since dmsetup access typically requires elevated privileges or group membership; User Interaction None (UI:N), as no user action is needed beyond issuing dmsetup commands; Scope Unchanged (S:U), as the impact is confined to the affected system; and Confidentiality, Integrity, and Availability all High (C:H/I:H/A:H), as out-of-bounds kernel memory writes can lead to information disclosure, code execution potential, and system crash. The score appropriately reflects the severity of kernel-level memory corruption, tempered by the local-only attack surface.

Frequently asked questions