Cloudanix VulnDB

CVE-2026-89576

None

CVSS

—

EPSS

0.2%

Published

Sep 11, 2026

CISA due date

—

Cloudanix analysis

Schedule a fix SSVC: Track

A bug in Linux storage snapshot handling can slowly use up internal tracking space when snapshot attempts fail, eventually stopping new snapshots from being created.

Exploitation
Local Privilege
Attacker needs
Local User
Complexity
Moderate
Impact
Denial Of Service
Component
OS kernel
Class
Memory Corruption
Remediation
Upgrade
Effort
Medium
Patch risk
Low

What it actually does

On error paths in metadata_take_snap after dm_tm_shadow_block succeeds but dm_sm_inc_block fails for writeset_tree_root or era_array_root, the allocated shadow block is never released via dm_sm_dec_block, permanently leaking one metadata block per failure.

Why it matters to the business

Repeated snapshot creation failures can exhaust limited metadata space over time, eventually preventing new snapshots or causing device-mapper operations to fail and disrupting storage management or backup workflows.

How an attack unfolds

An attacker with local access triggers repeated failed take-snap operations by inducing specific dm_sm_inc_block failures during snapshot metadata allocation; each failure leaks a block without attacker-controlled data placement, leading only to gradual resource exhaustion rather than direct code execution.

How to fix it

Update to a Linux kernel containing the fix that calls dm_sm_dec_block on the relevant error paths in metadata_take_snap; rebuild and reboot with the patched kernel.

How to confirm the fix worked

Confirm the presence of the dm_sm_dec_block call on the dm_sm_inc_block failure paths inside metadata_take_snap by inspecting the dm-era source; test by forcing the error conditions and verifying no net metadata block leak via space map counters.

Typical attack path

  1. Obtain local unprivileged access on a system using dm-era targets
  2. Repeatedly invoke snapshot creation operations that reach the error path after shadow block allocation
  3. Accumulate leaked metadata blocks until space map exhaustion occurs
  4. Observe denial of further snapshot or metadata operations

How to detect it

Review kernel logs for repeated dm-era snapshot failures around metadata allocation; correlate with increasing dm-era metadata block usage via device-mapper statistics if available.

What your security team should do

  • Prioritize kernel updates on systems actively using dm-era snapshots
  • Monitor kernel changelog for dm-era fixes in upcoming stable releases
  • Limit untrusted local access on storage servers until patched

The record

In the Linux kernel, the following vulnerability has been resolved: dm-era: fix shadowed superblock leak on take-snap failure metadata_take_snap() bumps the live superblock refcount and then dm_tm_shadow_block() allocates a new block for the metadata snapshot. If the subsequent dm_sm_inc_block() of writeset_tree_root or era_array_root fails, the function only unlocks the clone and returns. The newly allocated shadow block is never returned to the metadata space map, so each failed take-snap permanently leaks one metadata block. Free the clone with dm_sm_dec_block() on those error paths, matching the final step of metadata_drop_snap().

Affected packages

Ecosystem Package Introduced Fixed