CVE-2026-72108 in Linux
Summary
by MITRE • 08/15/2026
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.
If you want to get the best quality for vulnerability data then you always have to consider VulDB.
Analysis
by VulDB Data Team • 08/15/2026
The vulnerability resides within the Linux kernel's device mapper thin provisioning subsystem, specifically in the metadata handling mechanisms of the thin pool implementation. This issue affects the consistency of metadata snapshots during commit failures, creating potential data corruption scenarios that can lead to inconsistent reference counts and leaked blocks. The problem manifests when the block manager's buffer modifies the superblock's held_root field directly during metadata snapshot operations, without proper synchronization with the transaction commit lifecycle.
The technical flaw stems from the direct modification of the held_root field in the superblock's buffer by both __reserve_metadata_snap() and __release_metadata_snap() functions. When subsequent metadata commit operations fail, the abort_transaction path flushes the modified held_root to disk, resulting in metadata inconsistency between what is stored on disk and what should be logically correct. This behavior violates fundamental principles of transactional consistency where modifications should only be committed when the entire transaction succeeds, not partially applied during failure conditions.
The operational impact of this vulnerability extends beyond simple data corruption to potentially render thin-provisioned volumes unusable or cause severe data integrity issues. When metadata snapshots are taken under conditions that trigger commit failures, the system enters an inconsistent state where reference counts become mismatched and blocks may be leaked or left with stale references. This creates a scenario where thin_check utility reports bad reference counts and block leaks, indicating fundamental damage to the space map structures that track block allocation. The vulnerability affects both reservation and release operations, making it particularly dangerous as it can compromise metadata consistency during normal operational procedures.
The fix implements a deferred update strategy for the held_root field, ensuring that modifications only occur at commit time rather than during the snapshot reservation or release phases. This approach aligns with established database transaction principles where updates to persistent storage are synchronized with successful transaction completion. Additionally, the patch restructures the __reserve_metadata_snap function to perform existing-snapshot checks before shadow operations, eliminating unnecessary work and potential failure points. In __release_metadata_snap, the implementation clears pmd->held_root prior to btree deletion, ensuring that partial failures result in block leaks rather than stale references, which is a more predictable and recoverable state. This modification addresses both CWE-119 (Improper Access of Resources) and CWE-691 (Insufficient Protection of Data Structures) categories while implementing ATT&CK techniques related to persistence and privilege escalation through data corruption.
The mitigation strategy involves updating the device mapper thin provisioning subsystem to ensure proper transactional boundaries around metadata snapshot operations. System administrators should apply kernel patches that implement the deferred held_root update mechanism and verify metadata consistency using tools like thin_check after applying updates. Organizations maintaining thin-provisioned storage environments must monitor for potential inconsistencies following any system updates, particularly when dealing with metadata device configurations that might trigger commit failures during snapshot operations. The fix represents a fundamental improvement to the transaction management within the device mapper subsystem, ensuring data integrity through proper synchronization of in-memory state changes with on-disk persistence mechanisms.