CyberSecBulletin
CVE-2026-72108NVD status: Received

Linux: Operation on a Resource after Expiration or Release

Published Updated By the CyberSecBulletin desk

CVE-2026-72108 is a high-severity operation on a resource after expiration or release vulnerability in Linux, with a CVSS 3.1 base score of 7.8 out of 10. It can be exploited with local access to the system by an attacker with a low-privileged account, without any action from a user. The record lists versions 4af993468193cf4cd32ba5748786e7801945f7d2, abf2fae92cbe68945028987d498cc72f8f0e23a8, 5efb1a7734ed4035fa4fdc3716bdb84621f27cf6 as the first without the flaw, so updating Linux to one of those releases or later removes the exposure. There is no confirmed exploitation so far. EPSS estimates a 0.26% chance of exploitation within 30 days, which is low compared with other CVEs.

Next patch cycle

High severity with no evidence of exploitation so far.

What to do

  1. Update Linux to 4af993468193cf4cd32ba5748786e7801945f7d2 or abf2fae92cbe68945028987d498cc72f8f0e23a8 or 5efb1a7734ed4035fa4fdc3716bdb84621f27cf6 or 3dc9ae1029320d77472c44965e572f176949cd63, whichever matches your release line, or a later version.

Affected products and versions

VendorProductAffected versionsFixed in
LinuxLinux991d9fa02da0dd1f843dc011376965e0c8c6c9b5 up to, but not including, 4af993468193cf4cd32ba5748786e7801945f7d2; 991d9fa02da0dd1f843dc011376965e0c8c6c9b5 up to, but not including, abf2fae92cbe68945028987d498cc72f8f0e23a8; 991d9fa02da0dd1f843dc011376965e0c8c6c9b5 up to, but not including, 5efb1a7734ed4035fa4fdc3716bdb84621f27cf6; 991d9fa02da0dd1f843dc011376965e0c8c6c9b5 up to, but not including, 3dc9ae1029320d77472c44965e572f176949cd63; 991d9fa02da0dd1f843dc011376965e0c8c6c9b5 up to, but not including, b5f9a31c51cbb374a1713c3494f8660ab070f035; 991d9fa02da0dd1f843dc011376965e0c8c6c9b5 up to, but not including, 7f76245960a332f39b08cc556e675d1765dc5bbb; 991d9fa02da0dd1f843dc011376965e0c8c6c9b5 up to, but not including, 9f1a0d27586ceab055e6b050e3731ce3c6b2c4f0; 991d9fa02da0dd1f843dc011376965e0c8c6c9b5 up to, but not including, 5bcd4d3058ebaf46ad2e163829d87dd4870c7a45; and 1 more ranges4af993468193cf4cd32ba5748786e7801945f7d2, abf2fae92cbe68945028987d498cc72f8f0e23a8, 5efb1a7734ed4035fa4fdc3716bdb84621f27cf6, 3dc9ae1029320d77472c44965e572f176949cd63, b5f9a31c51cbb374a1713c3494f8660ab070f035, 7f76245960a332f39b08cc556e675d1765dc5bbb

Version data comes from the organisation that assigned the CVE. Confirm against the vendor advisory before deciding you are unaffected.

How the severity score breaks down

Attack vector
LocalThe attacker needs local access or must trick a user into running something.
Attack complexity
LowNo special conditions are needed; the attack works reliably.
Privileges required
LowA basic user account is enough.
User interaction
NoneNo action by a victim is required.
Scope
UnchangedImpact stays within the vulnerable component.
Confidentiality
HighAll data handled by the component can be read.
Integrity
HighData or code can be modified at will.
Availability
HighThe component can be taken down completely.

Vector: CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H. Scored by CNA.

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

Source: the CVE record as published by its numbering authority, via NVD and CVE.org.

The underlying weakness: Operation on a Resource after Expiration or Release

The product uses, accesses, or otherwise operates on a resource after that resource has been expired, released, or revoked.

More Operation on a Resource after Expiration or Release vulnerabilities (CWE-672)

Timeline

  1. CVE record published.
  2. CISA published its SSVC assessment (exploitation: none, automatable: no, technical impact: total).
  3. Record last changed materially (score, affected products, status or references).

References

Recent Operation on a Resource after Expiration or Release vulnerabilities

Spotted an error? Tell us.