Skip to main content
VulnerabilityPublished Updated

CVE-2026-72108: Linux kernel · dm thin metadata: fix metadata snapshot consistency on commit failure

Affects Linux kernelSource CVE Database V5

0

Not known to be exploited · CVSS 7.8 High · fixed in b5f9a31c51cbb374a1713c3494f8660ab070f035 : patch Linux kernel soon.

Data as of 26 Oct 2026, 10:24 UTC

CVSS 3.1 base score
7.8High
How severe the flaw is on the 0–10 CVSS scale.
EPSS
0.2% chance of exploitation in 30 days – higher than 17% of CVEsExploit Prediction Scoring System: the likelihood attackers will use this flaw soon.
CISA SSVC
Exploitation
No evidence of active exploitation and no public proof of concept
Automatable
Attackers cannot reliably automate steps 1–4 of the kill chain
Technical impact
Total control over the software or total information disclosure

CISA SSVC assessment, 2026-10-16.

Patch
Available – fixed in b5f9a31c51cbb374a1713c3494f8660ab070f035, abf2fae92cbe68945028987d498cc72f8f0e23a8, 9f1a0d27586ceab055e6b050e3731ce3c6b2c4f0 +5
CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H

Exploitation evidence

  1. Disclosed: evidence found.

    CVE published 15 Aug 2026

  2. Detectable: no evidence on record.

    No public nuclei template indexed

  3. Weaponised: no evidence on record.

    No public exploit code indexed in Metasploit or Exploit-DB

  4. Exploited in the wild: no evidence on record.

    Not in CISA KEV and no source reports exploitation

  5. Observed by OffSeq Mirage: no evidence on record.

    No attack traffic recorded by OffSeq Mirage sensors

A missing step is not evidence of safety. Sources: cve.org (opens in a new tab), the Metasploit, Exploit-DB and nuclei-templates index as of 26 Oct 2026.

What to do

Upgrade to a fixed release listed under Affected software.

Affected software

ProductAffectedFixed in
LinuxLinuxAffected
  • ≥ 991d9fa02da0dd1f843dc011376965e0c8c6c9b5, < b5f9a31c51cbb374a1713c3494f8660ab070f035
Fixed in
  • b5f9a31c51cbb374a1713c3494f8660ab070f035
LinuxLinuxAffected
  • ≥ 991d9fa02da0dd1f843dc011376965e0c8c6c9b5, < abf2fae92cbe68945028987d498cc72f8f0e23a8
Fixed in
  • abf2fae92cbe68945028987d498cc72f8f0e23a8
LinuxLinuxAffected
  • ≥ 991d9fa02da0dd1f843dc011376965e0c8c6c9b5, < 9f1a0d27586ceab055e6b050e3731ce3c6b2c4f0
Fixed in
  • 9f1a0d27586ceab055e6b050e3731ce3c6b2c4f0
LinuxLinuxAffected
  • ≥ 991d9fa02da0dd1f843dc011376965e0c8c6c9b5, < 7f76245960a332f39b08cc556e675d1765dc5bbb
Fixed in
  • 7f76245960a332f39b08cc556e675d1765dc5bbb
LinuxLinuxAffected
  • ≥ 991d9fa02da0dd1f843dc011376965e0c8c6c9b5, < 5efb1a7734ed4035fa4fdc3716bdb84621f27cf6
Fixed in
  • 5efb1a7734ed4035fa4fdc3716bdb84621f27cf6
LinuxLinuxAffected
  • ≥ 991d9fa02da0dd1f843dc011376965e0c8c6c9b5, < 5bcd4d3058ebaf46ad2e163829d87dd4870c7a45
Fixed in
  • 5bcd4d3058ebaf46ad2e163829d87dd4870c7a45

Description

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" 2. 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" 3. 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" 2. 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" 3. 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.

References

Community reviews

Loading reviews…