Linux Kernel bis 7.2-rc2 dm thin metadata __reserve_metadata_snap/__release_metadata_snap Local Privilege Escalation

CVSS Meta Temp ScoreAktueller Exploitpreis (≈)CTI Interest Score
7.8$0-$5k0.98-

Zusammenfassunginfo

Eine Schwachstelle wurde in Linux Kernel bis 7.2-rc2 gefunden. Sie wurde als sehr kritisch eingestuft. Hierbei geht es um die Funktion __reserve_metadata_snap/__release_metadata_snap der Komponente dm thin metadata. Durch Beeinflussen mit unbekannten Daten kann eine Local Privilege Escalation-Schwachstelle ausgenutzt werden. Die Verwundbarkeit wird unter CVE-2026-72108 geführt. Der Angriff erfordert einen lokalen Zugriff. Es ist soweit kein Exploit verfügbar.

Detailsinfo

In Linux Kernel bis 7.2-rc2 wurde eine Schwachstelle gefunden. Sie wurde als sehr kritisch eingestuft. Hierbei betrifft es die Funktion __reserve_metadata_snap/__release_metadata_snap der Komponente dm thin metadata. Mit der Manipulation mit einer unbekannten Eingabe kann eine Local Privilege Escalation-Schwachstelle ausgenutzt werden. CWE definiert das Problem als CWE-911. Auswirkungen hat dies auf Vertraulichkeit, Integrität und Verfügbarkeit. Die Zusammenfassung von CVE lautet:

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.

Bereitgestellt wird das Advisory unter git.kernel.org. Die Verwundbarkeit wird seit dem 09.08.2026 als CVE-2026-72108 geführt. Sie ist leicht ausnutzbar. Der Angriff muss lokal angegangen werden. Um eine Ausnutzung durchzusetzen, muss eine erweiterte Authentisierung umgesetzt werden. Technische Details sind bekannt, ein verfügbarer Exploit hingegen nicht. Ein Exploit zur Schwachstelle wird momentan etwa USD $0-$5k kosten (Preisberechnung vom 15.08.2026).

Ein Aktualisieren auf die Version 5.10.261, 5.15.212, 6.1.178, 6.6.145, 6.12.97, 6.18.40, 7.1.5 oder 7.2-rc3 vermag dieses Problem zu lösen. Die Schwachstelle lässt sich auch durch das Einspielen des Patches 4af993468193cf4cd32ba5748786e7801945f7d2/abf2fae92cbe68945028987d498cc72f8f0e23a8/5efb1a7734ed4035fa4fdc3716bdb84621f27cf6/3dc9ae1029320d77472c44965e572f176949cd63/b5f9a31c51cbb374a1713c3494f8660ab070f035/7f76245960a332f39b08cc556e675d1765dc5bbb/9f1a0d27586ceab055e6b050e3731ce3c6b2c4f0/5bcd4d3058ebaf46ad2e163829d87dd4870c7a45 lösen.

If you want to get the best quality for vulnerability data then you always have to consider VulDB.

Produktinfo

Typ

Hersteller

Name

Version

Lizenz

Webseite

CPE 2.3info

CPE 2.2info

CVSSv4info

VulDB Vector: 🔒
VulDB Zuverlässigkeit: 🔍

CVSSv3info

VulDB Meta Base Score: 8.2
VulDB Meta Temp Score: 7.8

VulDB Base Score: 8.2
VulDB Temp Score: 7.8
VulDB Vector: 🔒
VulDB Zuverlässigkeit: 🔍

CVSSv2info

AVACAuCIA
💳💳💳💳💳💳
💳💳💳💳💳💳
💳💳💳💳💳💳
VektorKomplexitätAuthentisierungVertraulichkeitIntegritätVerfügbarkeit
freischaltenfreischaltenfreischaltenfreischaltenfreischaltenfreischalten
freischaltenfreischaltenfreischaltenfreischaltenfreischaltenfreischalten
freischaltenfreischaltenfreischaltenfreischaltenfreischaltenfreischalten

VulDB Base Score: 🔒
VulDB Temp Score: 🔒
VulDB Zuverlässigkeit: 🔍

Exploitinginfo

Klasse: Local Privilege Escalation
CWE: CWE-911 / CWE-664
CAPEC: 🔒
ATT&CK: 🔒

Physisch: Teilweise
Lokal: Ja
Remote: Nein

Verfügbarkeit: 🔒
Status: Nicht definiert
Preisentwicklung: 🔍
Aktuelle Preisschätzung: 🔒

0-Dayfreischaltenfreischaltenfreischaltenfreischalten
Heutefreischaltenfreischaltenfreischaltenfreischalten

Threat Intelligenceinfo

Interesse: 🔍
Aktive Akteure: 🔍
Aktive APT Gruppen: 🔍

Gegenmassnahmeninfo

Empfehlung: Upgrade
Status: 🔍

0-Day Time: 🔒

Upgrade: Kernel 5.10.261/5.15.212/6.1.178/6.6.145/6.12.97/6.18.40/7.1.5/7.2-rc3
Patch: 4af993468193cf4cd32ba5748786e7801945f7d2/abf2fae92cbe68945028987d498cc72f8f0e23a8/5efb1a7734ed4035fa4fdc3716bdb84621f27cf6/3dc9ae1029320d77472c44965e572f176949cd63/b5f9a31c51cbb374a1713c3494f8660ab070f035/7f76245960a332f39b08cc556e675d1765dc5bbb/9f1a0d27586ceab055e6b050e3731ce3c6b2c4f0/5bcd4d3058ebaf46ad2e163829d87dd4870c7a45

Timelineinfo

09.08.2026 CVE zugewiesen
15.08.2026 +6 Tage Advisory veröffentlicht
15.08.2026 +0 Tage VulDB Eintrag erstellt
15.08.2026 +0 Tage VulDB Eintrag letzte Aktualisierung

Quelleninfo

Hersteller: kernel.org

Advisory: git.kernel.org
Status: Bestätigt

CVE: CVE-2026-72108 (🔒)
GCVE (CVE): GCVE-0-2026-72108
GCVE (VulDB): GCVE-100-390469

Eintraginfo

Erstellt: 15.08.2026 11:39
Anpassungen: 15.08.2026 11:39 (59)
Komplett: 🔍
Cache ID: 216::103

If you want to get the best quality for vulnerability data then you always have to consider VulDB.

Diskussion

Bisher keine Kommentare. Sprachen: de + en.

Bitte loggen Sie sich ein, um kommentieren zu können.

Do you know our Splunk app?

Download it now for free!