Skip to main content

Linux Kernel CVE-2026-72108

| EUVDEUVD-2026-59066 HIGH
2026-08-15 416baaa9-dc9f-4396-8d5f-8c081fb06d67 GHSA-j64h-56wh-mxm7
High
Disputed · 7.8 Vendor: 416baaa9-dc9f-4396-8d5f-8c081fb06d67
Share

Severity by source

Sources disagree (Low–High)
Vendor (416baaa9-dc9f-4396-8d5f-8c081fb06d67) PRIMARY
7.8 HIGH
AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H
vuln.today AI
7.3 HIGH

Local attack vector and low-privilege requirement confirmed; confidentiality impact assessed as Low rather than High because the description documents integrity and availability corruption, not direct data exposure.

3.1 AV:L/AC:L/PR:L/UI:N/S:U/C:L/I:H/A:H
4.0 AV:L/AC:L/AT:N/PR:L/UI:N/VC:L/VI:H/VA:H/SC:N/SI:N/SA:N
SUSE
3.4 LOW
AV:L/AC:L/PR:H/UI:N/S:U/C:N/I:L/A:L
Red Hat
5.5 MEDIUM
qualitative

vuln.today treats the vendor’s rating as authoritative. A higher third-party CVSS (e.g. CISA-ADP) is shown for transparency but does not drive the headline severity.

CVSS VectorVendor: 416baaa9-dc9f-4396-8d5f-8c081fb06d67

Attack Vector
Local
Attack Complexity
Low
Privileges Required
Low
User Interaction
None
Scope
Unchanged
Confidentiality
High
Integrity
High
Availability
High

Lifecycle Timeline

5
Analysis Generated
Aug 17, 2026 - 06:52 vuln.today
CVSS changed
Aug 17, 2026 - 06:22 NVD
7.8 (HIGH)
Patch available
Aug 15, 2026 - 07:20 EUVD
CVE Published
Aug 15, 2026 - 06:21 cve.org
HIGH 7.8
CVE Published
Aug 15, 2026 - 06:21 cve.org
UNKNOWN (no severity yet)

DescriptionCVE.org

In the Linux kernel, the following vulnerability has been resolved:

dm thin metadata: fix metadata snapshot consistency on commit failure

__reserve_metadata_snap() and __release_metadata_snap() modify the superblock's held_root directly in the block_manager's buffer. If the subsequent metadata commit fails, the held_root gets flushed to disk through the abort_transaction path, resulting in inconsistent metadata.

Reproducer 1: __reserve_metadata_snap()

  1. Create a 2 MiB metadata device and make the region after the 14th

block inaccessible, to trigger metadata commit failure in the subsequent reserve_metadata_snap operation. The 14th block will be the shadow destination for the index block.

dmsetup create tmeta --table "0 112 linear /dev/sdc 0 112 3984 error"

  1. Create a 16 MiB thin-pool

dmsetup create tdata --table "0 32768 zero" dd if=/dev/zero of=/dev/mapper/tmeta bs=4k count=1 dmsetup create tpool --table "0 32768 thin-pool /dev/mapper/tmeta \ /dev/mapper/tdata 128 0 1 skip_block_zeroing"

  1. Take a metadata snapshot to trigger metadata commit failure and

transaction abort. However, the held_root is written to disk, breaking metadata consistency.

dmsetup message tpool 0 "reserve_metadata_snap"

thin_check v1.2.2 result:

Bad reference count for metadata block 6. Expected 2, but space map contains 1. Bad reference count for metadata block 7. Expected 2, but space map contains 1. Bad reference count for metadata block 13. Expected 1, but space map contains 0.

Reproducer 2: __release_metadata_snap()

  1. Create a 2 MiB metadata device and make the region after the 16th

block inaccessible, to trigger metadata commit failure in the subsequent release_metadata_snap operation. The 16th block will be the shadow destination for the index block.

dmsetup create tmeta --table "0 128 linear /dev/sdc 0 128 3968 error"

  1. Create a 16 MiB thin-pool

dmsetup create tdata --table "0 32768 zero" dd if=/dev/zero of=/dev/mapper/tmeta bs=4k count=1 dmsetup create tpool --table "0 32768 thin-pool /dev/mapper/tmeta \ /dev/mapper/tdata 128 0 1 skip_block_zeroing"

  1. Reserve then release the metadata snapshot, to trigger metadata

commit failure and transaction abort. The held_root gets removed from the on-disk superblock, causing inconsistent metadata.

dmsetup message tpool 0 "reserve_metadata_snap" dmsetup message tpool 0 "release_metadata_snap"

thin_check v1.2.2 result:

Bad reference count for metadata block 6. Expected 1, but space map contains 2. Bad reference count for metadata block 7. Expected 1, but space map contains 2. 1 metadata blocks have leaked.

Fix by deferring the held_root update to commit time.

Additionally, move the existing-snapshot check in __reserve_metadata_snap before the shadow operation to avoid unnecessary work. In __release_metadata_snap, clear pmd->held_root before btree deletion so partial failure leaks blocks rather than leaving a stale reference, and unlock the snapshot block before decrementing its refcount.

AnalysisAI

Metadata snapshot operations in the Linux kernel's device-mapper thin provisioning (dm-thin) subsystem write a partially-updated superblock field to disk when a metadata commit subsequently fails, corrupting the on-disk space map reference counts. Systems using dm-thin storage pools are affected across a wide range of stable kernel branches from 3.2 onward through patched versions. A local attacker with access to dm-thin pool management can deliberately trigger the failure path - for example by constraining the metadata device - causing persistent metadata inconsistency that survives reboots and results in data loss or pool unavailability. No public exploit code exists and this vulnerability is not listed in CISA KEV at time of analysis.

Technical ContextAI

The dm-thin subsystem implements thin-provisioned block storage via a persistent B-tree metadata store managed by the block_manager layer. The functions __reserve_metadata_snap() and __release_metadata_snap() write the held_root field directly into the in-memory superblock buffer before the metadata commit completes. If the commit fails - for example, because the metadata device has inaccessible regions - the kernel's abort_transaction path still flushes the modified buffer to disk, persisting a held_root value that is inconsistent with the space map's reference counts. The CVE description provides two concrete reproductions: in the reserve path, reference counts for blocks 6, 7, and 13 become wrong; in the release path, one metadata block leaks. The fix defers the held_root update to commit time so the field is only persisted after a successful commit. The CWE field is not populated in available NVD data, but the root cause class is a time-of-check/time-of-commit inconsistency (TOCTOU-adjacent) combined with improper error handling in the abort path.

RemediationAI

The primary fix is to upgrade to a patched Linux kernel: 5.10.261, 5.15.212, 6.1.178, 6.6.145, 6.12.97, 6.18.40, 7.1.5, or 7.2-rc3 depending on the distribution's stable series. Distribution-specific packages (RHEL, Debian, Ubuntu, SUSE) should be applied via the standard package manager as vendor advisories are issued. For systems that cannot be immediately patched and that do not operationally require dm-thin metadata snapshots, the reserve_metadata_snap and release_metadata_snap dmsetup message commands can be administratively restricted - for example, by tightening device-mapper access controls or preventing unprivileged users from issuing dmsetup messages - to reduce exposure. This does not eliminate the underlying bug but limits who can trigger the failure path. Systems using LVM thin pools should audit whether automated snapshot tooling invokes these paths and consider suspending snapshot operations until patched. No vendor advisory URL beyond kernel.org stable commits is available at time of analysis.

Vendor StatusVendor

SUSE

Severity: Low
Product Status
SUSE Linux Enterprise Desktop 15 SP7 Affected
SUSE Linux Enterprise Desktop 15 SP7 Affected
SUSE Linux Enterprise High Availability Extension 15 SP7 Affected
SUSE Linux Enterprise High Availability Extension 15 SP7 Affected
SUSE Linux Enterprise High Availability Extension 16.0 Affected

Share

CVE-2026-72108 vulnerability details – vuln.today

This site uses cookies essential for authentication and security. No tracking or analytics cookies are used. Privacy Policy