CVE-2026-72108

This CVE exposes a transaction boundary violation in the dm-thin metadata subsystem. The bug lives in two functions — __reserve_metadata_snap() and __release_metadata_snap() — which modify the superblock's held_root field directly in the block_manager's buffer *before* the metadata commit succeeds. The developers assumed that if the commit failed, the abort path would implicitly restore the old held_root value. It doesn't. The abort path aborts the transaction but has no awareness that held_root was modified, so the modified buffer still flushes to disk. The result is metadata corruption that expresses two ways depending on timing. If held_root was being set when the commit aborts, you get negative reference counts — blocks appear over-freed. If held_root was being cleared when the commit aborts, you get positive reference counts — blocks appear double-allocated. Both states are fatal to the metadata device and trigger thin_check failures. The fix defers the held_root update to commit time, ensuring the modification only survives if the transaction succeeds. This is textbook transactional integrity: move side effects out of the prepare phase. The secondary fix in __release_metadata_snap clears held_root *before* btree deletion so that partial failure leaks blocks rather than leaving a stale reference — deliberately choosing detectable resource waste over undetectable silent corruption. This matters operationally because dm-thin underpins container runtimes, cloud instances, and infrastructure tooling. When the abort path flushes corrupted held_root, you're corrupting the metadata fabric that multiple volumes depend on, not a single thin device. The partial failure mode is particularly insidious: a volume that appears functional but has silently leaked blocks and lost metadata snapshot capability, with corruption spreading laterally as subsequent operations build on a broken foundation. The broader pattern — modifying state before commit, then depending on abort to undo it — has CVE ancestors in the JBD/JBD2 journal layer. The correct solution (defer updates to commit time) was already documented in those fixes. The dm-thin team either didn't retrieve that precedent or assumed the block_manager's rollback semantics included reverting arbitrary buffer modifications. That assumption was wrong: the abort path cannot distinguish transaction-bound modifications from independent ones. What to check: verify that your dm-thin metadata devices were created or resized under I/O fault conditions that could have triggered partial commits. Run thin_check on any metadata device that experienced unexplained corruption or I/O errors during thin provisioning operations. Prioritize this fix in containerized environments where dm-thin underpins storage for multiple workloads.

Reviewed through automated stages and approved by a human before publication.