CVE-2026-46107

What it actually does

This is a local Linux kernel flaw in the device-mapper thin provisioning driver, dm-thin. A metadata B-tree rebalance path can mishandle reference counts when an internal node with one entry points to a shared child node. The code may create additional references to grandchild metadata blocks without incrementing their reference counts, causing metadata reference-count underflow and inconsistent thin-pool metadata. In practical terms, a local user able to trigger relevant thin-provisioning metadata operations may be able to corrupt device-mapper metadata, disrupt storage availability, and potentially influence kernel memory or storage state in ways consistent with the assigned privilege-escalation impact.

Why it matters to the business

Systems using Linux thin-provisioned storage, including LVM thin pools and device-mapper thin volumes, may be exposed to local attacks that can destabilize storage, corrupt thin-pool metadata, or potentially allow elevation of privileges. The operational risk is highest on multi-user Linux servers, virtualization hosts, container platforms, build systems, and storage-backed platforms where untrusted or semi-trusted users can cause thin-volume creation, deletion, snapshotting, resizing, or heavy metadata churn. Although there is no known public exploit or CISA KEV listing, the CVSS score is high and the flaw affects a core kernel storage component, so remediation should be handled through normal high-priority kernel patching cycles.

How an attack unfolds

An attacker first needs local access to a Linux system and enough permissions or indirect capability to exercise dm-thin operations, such as thin volume allocation, snapshot creation, deletion, or workloads that force thin-pool metadata B-tree rebalancing. The attacker then drives metadata changes that cause an internal B-tree node with a single entry to be rebalanced while its child node is shared. On vulnerable kernels, the rebalance operation can duplicate pointers to grandchild metadata blocks without updating those blocks' reference counts. Later metadata updates or frees can decrement reference counts that no longer match the actual number of references, producing underflow conditions and metadata inconsistency. Depending on kernel behavior, storage layout, and attacker control over the triggering sequence, the outcome may range from kernel log errors and thin-pool corruption to denial of service or potential local privilege escalation.

How to fix it

Upgrade the Linux kernel to a vendor-supported release that contains the dm-thin metadata reference-count fix for CVE-2026-46107. No universal upstream fixed package version was provided in the input, so use the relevant distribution or appliance vendor advisory for exact kernel package versions. After patching, reboot into the fixed kernel; live patching is only sufficient if the vendor explicitly states that this dm-thin fix is covered. Where immediate patching is not possible, reduce exposure by limiting local shell access, restricting users who can run LVM/device-mapper operations, disabling unneeded thin-provisioned storage features, avoiding untrusted workloads on hosts using dm-thin, and ensuring thin-pool metadata backups and recovery procedures are current. For systems already showing dm-thin metadata errors, follow vendor recovery guidance before performing further thin-volume operations, as continued writes may worsen metadata inconsistency.

How to confirm the fix worked

Confirm that the running kernel version is at or above the vendor-fixed release, not merely that a patched package is installed. On Linux systems, compare `uname -r` with the fixed kernel identified by the operating system vendor and verify the booted kernel package using the package manager. Check whether dm-thin is in use with tools such as `dmsetup`, `lvs`, and `lsmod`, focusing on thin pools and thin volumes. Review kernel logs after patching and rebooting to ensure new dm-thin metadata underflow messages are no longer appearing. If thin-pool metadata was previously unhealthy, run vendor-supported validation tools such as LVM checks, `thin_check`, or storage-platform health checks before returning the system to normal operation.

Typical attack path

1. Obtain local access to a vulnerable Linux system.
2. Identify that device-mapper thin provisioning is in use, for example through LVM thin pools, dm-thin devices, snapshots, or container/virtualization storage layers.
3. Trigger repeated thin-provisioning metadata operations such as creating, deleting, snapshotting, resizing, or writing to thin volumes to force B-tree metadata rebalancing.
4. Cause the vulnerable rebalance path to process a shared child node without properly incrementing grandchild reference counts.
5. Continue metadata operations until reference-count underflow or metadata inconsistency occurs.
6. Leverage the resulting storage/kernel inconsistency to cause denial of service, corrupt thin-pool metadata, or attempt local privilege escalation depending on exploit reliability and system configuration.

How to detect it

Look for evidence of exploitation or attempted triggering in kernel, system, audit, and storage-management logs. Primary sources include `dmesg`, `journalctl -k`, `/var/log/kern.log`, `/var/log/messages`, `/var/log/syslog`, auditd command execution logs, sudo logs, shell history where available, and LVM/device-mapper operational logs. Search for device-mapper thin-provisioning metadata errors, especially reference-count or block-decrement failures, around the same time as high-volume thin-volume creation, deletion, snapshot, merge, resize, or write activity. Review executions of `dmsetup`, `lvm`, `lvcreate`, `lvremove`, `lvconvert`, `lvresize`, `thin_check`, `thin_dump`, and `thin_repair` by unexpected users or services. Treat the log message `device mapper: space map common: unable to decrement block` as a strong indicator of the vulnerable failure mode or metadata damage, though not definitive proof of malicious exploitation. Also investigate unexplained thin-pool read-only transitions, metadata exhaustion, kernel storage warnings, crashes, or service outages involving dm-thin devices.

• device mapper: space map common: unable to decrement block
• dm-thin
• thin pool
• thin-pool
• metadata refcount
• refcount underflow
• unable to decrement block
• thin_check
• thin_repair
• thin_dump
• dmsetup
• lvcreate
• lvremove
• lvconvert
• lvresize
• lvchange
• lvrename
• lvmerge
• /var/log/kern.log
• /var/log/messages
• /var/log/syslog

What your security team should do

• Prioritize patching Linux systems that use LVM thin pools, device-mapper thin provisioning, virtualization storage, container storage backends, or shared multi-user workloads.
• Confirm the fix is active by validating the running kernel after reboot; do not rely only on package installation status.
• Inventory where dm-thin is enabled using configuration management, EDR telemetry, or fleet scripts that query LVM/device-mapper state.
• Restrict access to commands and service interfaces that can create, delete, snapshot, resize, or otherwise manipulate thin volumes until patching is complete.
• Monitor kernel logs for dm-thin and device-mapper metadata underflow errors, especially on systems with untrusted local users or recent storage instability.
• Back up thin-pool metadata and verify recovery procedures for critical systems before applying disruptive maintenance or repair actions.
• Investigate any recent unexplained thin-pool corruption, kernel storage errors, or local-user activity involving `dmsetup`, `lvm`, `lvcreate`, `lvremove`, `lvconvert`, or snapshot operations.