CVE-2026-72108

HIGHPre-NVD 7.87.8
EchelonGraph scoreHIGH confidence

Score 7.8 from GitHub Security Advisory (severity: HIGH) published 2026-08-15. a secondary CVSS source baseline 7.8; sources differ by 0.0.

Triggered by: GitHub Security Advisory CVSS
Sources: epss, ghsa, secondary
Trending — 5 sources updated this week
7.8EG
EchelonGraph verdictPlan a fixSerious severity, but no confirmed exploitation yet.
  • High severity, but no confirmed exploitation yet
CISA-KEV: Not listedEPSS PROB: 0%CVSS: 7.8Exploit: None knownExposed: 0

No vendor fix yet — apply a workaround or compensating control (WAF / firewall / segmentation) and watch for a patch.

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()

  • 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"

  • 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"

  • 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()

  • 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"

  • 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"

  • 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.

CVSS v3
7.8
EG Score
7.8(high)
EG Risk
40(Track)
EG Risk 40/100SSVC: Track

EG Risk is EchelonGraph's 0–100 priority score: it fuses intrinsic severity with real-world exploitation and automatability so you can rank equal-severity CVEs and fix the most dangerous first. Higher = act sooner. Distinct from the 0–10 EG Score (severity).

How it’s computed
Severity78% × 45%
Exploitation0% × 40%
Automatability30% × 15%
Action: Routine — remediate on your standard cadence.
EPSS PROB
0%
EPSS %ILE
6%
KEV
Not listed

Published

August 15, 2026

Last Modified

August 17, 2026

Advisory Details (8)

Auto-updated Aug 17, 2026
No patch confirmed yet.
generic

dm thin metadata: fix metadata snapshot consistency on commit failure - kernel/git/stable/linux.git - Linux kernel stable tree

https://git.kernel.org/stable/c/b5f9a31c51cbb374a1713c3494f8660ab070f035
generic

dm thin metadata: fix metadata snapshot consistency on commit failure - kernel/git/stable/linux.git - Linux kernel stable tree

https://git.kernel.org/stable/c/abf2fae92cbe68945028987d498cc72f8f0e23a8
generic

dm thin metadata: fix metadata snapshot consistency on commit failure - kernel/git/stable/linux.git - Linux kernel stable tree

https://git.kernel.org/stable/c/9f1a0d27586ceab055e6b050e3731ce3c6b2c4f0
generic

dm thin metadata: fix metadata snapshot consistency on commit failure - kernel/git/stable/linux.git - Linux kernel stable tree

https://git.kernel.org/stable/c/7f76245960a332f39b08cc556e675d1765dc5bbb
generic

dm thin metadata: fix metadata snapshot consistency on commit failure - kernel/git/stable/linux.git - Linux kernel stable tree

https://git.kernel.org/stable/c/5efb1a7734ed4035fa4fdc3716bdb84621f27cf6
generic

dm thin metadata: fix metadata snapshot consistency on commit failure - kernel/git/stable/linux.git - Linux kernel stable tree

https://git.kernel.org/stable/c/5bcd4d3058ebaf46ad2e163829d87dd4870c7a45
generic

dm thin metadata: fix metadata snapshot consistency on commit failure - kernel/git/stable/linux.git - Linux kernel stable tree

https://git.kernel.org/stable/c/4af993468193cf4cd32ba5748786e7801945f7d2
generic

dm thin metadata: fix metadata snapshot consistency on commit failure - kernel/git/stable/linux.git - Linux kernel stable tree

https://git.kernel.org/stable/c/3dc9ae1029320d77472c44965e572f176949cd63

Vendor Advisories for CVE-2026-72108(1)

These vendors published their own advisory mentioning this CVE — often with vendor-specific remediation steps + affected product lists not in NVD.

Data Freshness Timeline

(refreshed 32× in last 7d / 32× in last 30d)

Each row is a source pipeline that fetched or updated this CVE on that date, with what changed. For example, "NVD update" means NVD published or revised its analysis for this CVE; "MITRE cvelistV5" means we ingested or refreshed it from the CNA feed. Most recent first.

  1. 2026-08-21 05:01 UTCEG score recompute
  2. 2026-08-21 05:01 UTCGHSA enrichment
  3. 2026-08-20 22:56 UTCEPSS rescore
  4. 2026-08-20 17:29 UTCGHSA enrichment
  5. 2026-08-20 05:57 UTCGHSA enrichment
  6. 2026-08-19 18:25 UTCEG score recompute
  7. 2026-08-19 18:25 UTCGHSA enrichment
  8. 2026-08-19 17:04 UTCEPSS rescore
  9. 2026-08-19 05:41 UTCGHSA enrichment
  10. 2026-08-18 18:10 UTCEG score recompute
  11. 2026-08-18 18:09 UTCGHSA enrichment
  12. 2026-08-18 13:49 UTCEPSS rescore
  13. 2026-08-18 13:49 UTCEPSS rescore
  14. 2026-08-18 06:33 UTCGHSA enrichment
  15. 2026-08-17 19:02 UTCEG score recompute
  16. 2026-08-17 19:01 UTCGHSA enrichment
  17. 2026-08-17 13:47 UTCEPSS rescore
  18. 2026-08-17 06:21 UTCEG score recompute
  19. 2026-08-17 06:21 UTCGHSA enrichment
  20. 2026-08-17 06:00 UTCEG score recompute 7.80
  21. 2026-08-17 06:00 UTCGHSA enrichment
  22. 2026-08-17 05:54 UTCMITRE cvelistV5CVSS v3 → 7.8 · severity → HIGH
  23. 2026-08-17 05:33 UTCEG score recompute
  24. 2026-08-17 05:33 UTCGHSA enrichment
  25. 2026-08-17 05:24 UTCMITRE cvelistV5
Show 7 more
  1. 2026-08-16 14:56 UTCEPSS rescore
  2. 2026-08-16 14:56 UTCEPSS rescore
  3. 2026-08-16 02:15 UTCEPSS rescore
  4. 2026-08-15 06:43 UTCGHSA enrichment
  5. 2026-08-15 06:23 UTCNVD update
  6. 2026-08-15 06:12 UTCEG score recompute
  7. 2026-08-15 06:02 UTCMITRE cvelistV5first tracked

Frequently asked(5)

What is CVE-2026-72108?
CVE-2026-72108 is a high vulnerability published on August 15, 2026. In the Linux kernel, the following vulnerability has been resolved: dm thin metadata: fix metadata snapshot consistency on commit failure reservemetadatasnap() and releasemetadatasnap() modify the superblock's heldroot directly in the blockmanager's buffer. If the subsequent metadata commit fails,…
When was CVE-2026-72108 disclosed?
CVE-2026-72108 was first published in the National Vulnerability Database on August 15, 2026, with the most recent update on August 17, 2026. EchelonGraph re-ingests CVE updates from NVD on a 2-hour cycle, so this page reflects the latest published state.
Is CVE-2026-72108 actively exploited?
CVE-2026-72108 is not currently on CISA's Known Exploited Vulnerabilities catalog. FIRST EPSS estimates a 0% probability of exploitation in the next 30 days, which ranks it in the top 93.9% of all scored CVEs.
What is the CVSS score of CVE-2026-72108?
CVE-2026-72108 has a CVSS v3 base score of 7.8 (NVD).
How do I remediate CVE-2026-72108?
Patch to the fixed version published by the affected vendor. Where vendor advisories exist for CVE-2026-72108, EchelonGraph cross-links them in the Vendor Advisories panel below — those typically contain the canonical remediation steps, fixed version numbers, and any vendor-specific mitigations.

Dependency Blast Radius

Explore the affected products and dependency analysis for CVE-2026-72108

Explore →

Is Your Infrastructure Affected by CVE-2026-72108?

EchelonGraph automatically scans your cloud infrastructure and maps CVE exposure using blast radius analysis.