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

From: Greg Kroah-Hartman <[email protected]>

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.

The Linux kernel CVE team has assigned CVE-2026-72108 to this issue.


Affected and fixed versions
===========================

	Issue introduced in 3.2 with commit 991d9fa02da0dd1f843dc011376965e0c8c6c9b5 and fixed in 5.10.261 with commit 4af993468193cf4cd32ba5748786e7801945f7d2
	Issue introduced in 3.2 with commit 991d9fa02da0dd1f843dc011376965e0c8c6c9b5 and fixed in 5.15.212 with commit abf2fae92cbe68945028987d498cc72f8f0e23a8
	Issue introduced in 3.2 with commit 991d9fa02da0dd1f843dc011376965e0c8c6c9b5 and fixed in 6.1.178 with commit 5efb1a7734ed4035fa4fdc3716bdb84621f27cf6
	Issue introduced in 3.2 with commit 991d9fa02da0dd1f843dc011376965e0c8c6c9b5 and fixed in 6.6.145 with commit 3dc9ae1029320d77472c44965e572f176949cd63
	Issue introduced in 3.2 with commit 991d9fa02da0dd1f843dc011376965e0c8c6c9b5 and fixed in 6.12.97 with commit b5f9a31c51cbb374a1713c3494f8660ab070f035
	Issue introduced in 3.2 with commit 991d9fa02da0dd1f843dc011376965e0c8c6c9b5 and fixed in 6.18.40 with commit 7f76245960a332f39b08cc556e675d1765dc5bbb
	Issue introduced in 3.2 with commit 991d9fa02da0dd1f843dc011376965e0c8c6c9b5 and fixed in 7.1.5 with commit 9f1a0d27586ceab055e6b050e3731ce3c6b2c4f0
	Issue introduced in 3.2 with commit 991d9fa02da0dd1f843dc011376965e0c8c6c9b5 and fixed in 7.2-rc3 with commit 5bcd4d3058ebaf46ad2e163829d87dd4870c7a45

Please see https://www.kernel.org for a full list of currently supported
kernel versions by the kernel community.

Unaffected versions might change over time as fixes are backported to
older supported kernel versions.  The official CVE entry at
	https://cve.org/CVERecord/?id=CVE-2026-72108
will be updated if fixes are backported, please check that for the most
up to date information about this issue.


Affected files
==============

The file(s) affected by this issue are:
	drivers/md/dm-thin-metadata.c


Mitigation
==========

The Linux kernel CVE team recommends that you update to the latest
stable kernel version for this, and many other bugfixes.  Individual
changes are never tested alone, but rather are part of a larger kernel
release.  Cherry-picking individual commits is not recommended or
supported by the Linux kernel community at all.  If however, updating to
the latest release is impossible, the individual changes to resolve this
issue can be found at these commits:
	https://git.kernel.org/stable/c/4af993468193cf4cd32ba5748786e7801945f7d2
	https://git.kernel.org/stable/c/abf2fae92cbe68945028987d498cc72f8f0e23a8
	https://git.kernel.org/stable/c/5efb1a7734ed4035fa4fdc3716bdb84621f27cf6
	https://git.kernel.org/stable/c/3dc9ae1029320d77472c44965e572f176949cd63
	https://git.kernel.org/stable/c/b5f9a31c51cbb374a1713c3494f8660ab070f035
	https://git.kernel.org/stable/c/7f76245960a332f39b08cc556e675d1765dc5bbb
	https://git.kernel.org/stable/c/9f1a0d27586ceab055e6b050e3731ce3c6b2c4f0
	https://git.kernel.org/stable/c/5bcd4d3058ebaf46ad2e163829d87dd4870c7a45