Cloudanix VulnDB

CVE-2026-99086

None

CVSS

—

EPSS

0.2%

Published

Oct 23, 2026

CISA due date

—

Cloudanix analysis

Schedule a fix SSVC: Track

A flaw in Linux storage integrity handling lets someone who can change disk metadata while a device is paused cause the system to crash or corrupt memory when the device is restarted.

Exploitation
Local Privilege
Attacker needs
High Privilege
Complexity
Moderate
Impact
Denial Of Service
Component
OS kernel
Class
Improper Input Validation
Remediation
Patch
Effort
Medium
Patch risk
Low

What it actually does

dm-integrity skips superblock validation on resume, allowing tampered on-disk geometry (log2_sectors_per_block) to cause journal index calculation to exceed allocated journal pages and trigger a 512-byte write through a NULL page address.

Why it matters to the business

Adversaries able to alter storage while the mapping is suspended can trigger kernel memory corruption or crashes on resume, resulting in loss of data-integrity protection and unplanned downtime for affected Linux storage configurations.

How an attack unfolds

An attacker with write access to the underlying block device modifies the dm-integrity superblock while the target mapping is suspended; on resume dm_integrity_resume reads the altered superblock without validation, recomputes journal layout inconsistently with constructor-time values, and access_journal_data performs an out-of-bounds write that dereferences NULL.

How to fix it

Apply the upstream kernel patch that snapshots the validated superblock at constructor time and refuses resume when geometry fields differ; rebuild and reboot with a fixed kernel version containing the dm-integrity validation change.

How to confirm the fix worked

Confirm the patch is present by checking for the added superblock field comparison and early return in dm_integrity_resume; test by suspending a dm-integrity device, altering its superblock on-disk, and verifying resume is rejected.

Typical attack path

  1. Obtain write access to the block device backing a suspended dm-integrity mapping
  2. Alter the superblock fields that encode journal geometry (especially log2_sectors_per_block)
  3. Resume the dm-integrity device
  4. Trigger journal access so that the miscalculated index writes through a NULL page

How to detect it

Look in kernel logs for NULL pointer dereference or page-fault traces involving dm-integrity journal functions immediately after a device resume; correlate with audit records showing the dm device was suspended then resumed.

What your security team should do

  • Prioritize patching all Linux kernels that use dm-integrity within the next maintenance window
  • Audit systems for active dm-integrity mappings and ensure they are not left suspended for long periods
  • Monitor upstream stable kernel releases for the backported fix and schedule immediate updates

The record

In the Linux kernel, the following vulnerability has been resolved: dm-integrity: validate the superblock on resume dm_integrity_resume() re-reads the superblock from the device so that it picks up the flags and the recalculate position. It performs no validation on the result, while the constructor validates the superblock it reads and sizes all the in-memory structures according to it. The user may modify the superblock on the underlying device while the dm-integrity device is suspended, so that the two no longer agree. In particular, access_journal_data() shifts the journal entry index by ic->sb->log2_sectors_per_block, while ic->journal_section_sectors and the journal page list were computed with the value that was present at constructor time. Increasing log2_sectors_per_block makes the index run past the end of the journal, and dm-integrity then writes 512 bytes through lowmem_page_address(NULL). Snapshot the validated superblock in the constructor and refuse to resume if any of the fields that describe the on-disk geometry changed.

Affected packages

Ecosystem Package Introduced Fixed