CVE-2026-46023

What it actually does

This is a local Linux kernel device-mapper mirror flaw caused by an unsigned integer overflow in create_dirty_log(). A crafted device-mapper mirror table can supply a dirty-log parameter count near UINT_MAX, causing the calculation of required arguments to wrap to a small value and bypass validation. The overflowed count is then passed into dm_dirty_log_create(), which can read beyond the provided argv array. The practical impact is primarily kernel memory safety failure leading to a crash, kernel oops, or denial of service. Exploitation requires local privileges sufficient to create or reload device-mapper tables, typically root, CAP_SYS_ADMIN, or an equivalent delegated storage-management role.

Why it matters to the business

Successful exploitation can crash or destabilize a Linux host that uses or allows device-mapper operations, causing service outages, failed storage operations, interrupted workloads, and possible data unavailability until the system is recovered. Because this is a local denial-of-service issue with low EPSS, no known public exploit maturity, and no CISA KEV listing, broad internet-scale exploitation is unlikely; however, it remains important for shared Linux systems, virtualization hosts, storage appliances, CI runners, and environments where users or automation can invoke device-mapper configuration changes.

How an attack unfolds

An attacker first needs local access to the Linux system and the ability to issue device-mapper control operations. They then submit a crafted device-mapper mirror table, usually through dmsetup or equivalent tooling that talks to /dev/mapper/control. The malicious table sets the dirty-log parameter count to an extremely large unsigned value close to 4294967295. In vulnerable kernels, create_dirty_log() adds 2 to that value before checking it against the actual argument count. The addition wraps around, making the required argument count appear small enough to pass validation. The kernel then calls dm_dirty_log_create() with the attacker-controlled large count, causing out-of-bounds reads while processing the argument vector. Depending on memory layout and kernel hardening, this can trigger a kernel oops, panic, or unstable device-mapper behavior, resulting in local denial of service.

How to fix it

Upgrade to a Linux kernel version that contains the upstream fix for the dm mirror create_dirty_log() integer-overflow validation issue. The corrected logic validates param_count against argc - 2 before adding 2, preventing unsigned wraparound. If vendor-fixed package versions are not yet listed, obtain the patched kernel from the operating system or appliance vendor and prioritize systems where untrusted users, containers, build jobs, storage orchestration, or automation may have access to device-mapper operations. As mitigations until patching is complete, restrict access to /dev/mapper/control, limit CAP_SYS_ADMIN and storage-management privileges, prevent untrusted users from running dmsetup or libdevmapper-based tooling, and ensure container runtimes do not grant device-mapper control access into containers unless strictly required.

How to confirm the fix worked

Confirm remediation by verifying that the running kernel includes the vendor patch for the dm mirror create_dirty_log() fix, not merely that an updated package is installed. Check the active kernel with uname -r and compare it with the vendor advisory or changelog for this vulnerability. On source-based or custom kernels, confirm that drivers/md/dm-raid1.c validates param_count against argc - 2 before computing args_used. Validate exposure by checking whether device-mapper mirror support is available and whether local users or workloads can access /dev/mapper/control or run dmsetup. After patching, reboot into the fixed kernel if required and confirm no vulnerable kernel remains active or configured as the default boot entry.

Typical attack path

1. Obtain local shell or code execution on a Linux host.
2. Gain or abuse permission to perform device-mapper table operations, typically root, CAP_SYS_ADMIN, or access to storage-management automation.
3. Use dmsetup, libdevmapper, or direct device-mapper ioctls against /dev/mapper/control.
4. Submit a crafted mirror target table with a dirty-log parameter count near the maximum unsigned integer value.
5. Trigger the vulnerable create_dirty_log() argument-count calculation during table load or reload.
6. Cause dm_dirty_log_create() to process an invalid oversized argument count, leading to out-of-bounds reads.
7. Induce kernel oops, panic, device-mapper failure, or host denial of service.

How to detect it

Look for evidence of prior exploitation in host audit logs, command-line telemetry, process accounting, shell history, kernel logs, and crash dumps. Useful sources include auditd records for executions of dmsetup and access to /dev/mapper/control, EDR process events showing dmsetup or libdevmapper-based utilities loading or reloading mirror tables, sudo logs for storage-management commands, bash/zsh history for device-mapper table operations, and kernel logs from dmesg, journalctl -k, /var/log/kern.log, /var/log/messages, or crash dump tooling. Suspicious indicators include device-mapper mirror table load or reload attempts with extremely large numeric parameters, especially values close to 4294967295, followed by kernel oops, panic, BUG, page fault, general protection fault, or call traces containing create_dirty_log(), dm_dirty_log_create(), dm_mirror, or dm-raid1. Because successful exploitation may only leave crash artifacts and not a clean application log entry, correlate sudden host reboots or storage-service disruption with recent local device-mapper control operations.

• /dev/mapper/control
• dmsetup
• dmsetup create
• dmsetup load
• dmsetup reload
• dmsetup resume
• dmsetup table
• mirror
• dm_dirty_log_create
• create_dirty_log
• dm-raid1
• dm_mirror
• 4294967295
• 4294967294
• 4294967293
• kernel BUG
• kernel panic
• general protection fault
• Oops:
• Call Trace:

What your security team should do

• Prioritize patching Linux hosts where local users, containers, CI jobs, storage automation, or virtualization workflows can interact with device-mapper.
• Inventory systems with device-mapper mirror support and review whether /dev/mapper/control is accessible outside trusted administrative contexts.
• Restrict CAP_SYS_ADMIN, privileged containers, and direct device-mapper access to the smallest possible set of trusted administrators and services.
• Monitor for unusual dmsetup create, load, reload, suspend, resume, or table operations, especially from non-administrative accounts or automation that does not normally manage storage.
• Review kernel logs for oops, panic, BUG, general protection fault, or call traces involving create_dirty_log(), dm_dirty_log_create(), dm_mirror, or dm-raid1.
• If suspicious activity is found, preserve kernel logs, audit logs, shell history, process accounting, and command-line telemetry before rebooting or rebuilding the host.
• Treat unexpected kernel crashes following device-mapper table activity as potentially malicious until storage-management activity is explained.