Cloudanix VulnDB

CVE-2026-89574

High · 7.8

CVSS

7.8

EPSS

0.2%

Published

Sep 11, 2026

CISA due date

—

Cloudanix analysis

Schedule a fix SSVC: Track

A bug in Linux storage handling lets a logged-in user crash the machine or potentially take it over by feeding bad numbers into internal data structures.

Exploitation
Local Privilege
Attacker needs
Low Privilege
Complexity
Low
Impact
Full Compromise
Component
OS kernel
Class
Improper Input Validation
Remediation
Upgrade
Effort
Medium
Patch risk
Low

What it actually does

Out-of-bounds read caused by missing validation of dm-array on-disk header fields; dm_array_cursor_next derives its loop bound from an attacker-controlled nr_entries value while element_at performs unguarded pointer arithmetic, allowing reads past the end of the dm-bufio buffer when a cache mapping load occurs.

Why it matters to the business

Local attackers on Linux systems that use device-mapper caching can trigger kernel memory corruption, resulting in crashes, denial of service, or potential privilege escalation to full system control.

How an attack unfolds

An attacker prepares a dm-array metadata block on disk with a crafted nr_entries value larger than the block capacity; when dm-cache activates it calls dm_cache_load_mappings which drives dm_array_cursor_next, causing the cursor to walk off the end of the allocated buffer and read attacker-controlled memory.

How to fix it

Apply the upstream kernel commit that augments array_block_check to reject zero value_size, enforce max_entries == calc_max_entries(value_size, block_size), and require nr_entries to fit within the block; rebuild and reboot with the patched kernel.

How to confirm the fix worked

Confirm the running kernel source contains the three new header checks inside array_block_check and that dm_array_cursor_next and element_at no longer rely on unvalidated on-disk counts.

Typical attack path

  1. Place a malicious dm-array metadata block with oversized nr_entries on storage
  2. Trigger dm-cache device activation or mapping load
  3. Force dm_array_cursor_next iteration that performs out-of-bounds pointer arithmetic

How to detect it

Search kernel logs and crash dumps for symbols dm_array_cursor_next, array_block_check, dm_cache_load_mappings, and BUG_ON calls inside fill_ablock or trim_ablock; inspect on-disk dm-array superblocks and array blocks for nr_entries or value_size values that fail the new validation rules.

  • dm_array_cursor_next
  • array_block_check
  • dm_cache_load_mappings
  • BUG_ON.*fill_ablock
  • BUG_ON.*trim_ablock

What your security team should do

  • Immediately update Linux kernels on all systems that expose device-mapper cache targets
  • Disable dm-cache on untrusted or multi-tenant hosts until patched
  • Add kernel crash and oops monitoring for dm-bufio and dm-array symbols

The record

In the Linux kernel, the following vulnerability has been resolved: dm array: validate array block headers on read array_block_check() validates blocknr and csum and nothing else, while node_check(), next to it, has bounded the structural fields since both were written. dm_array_cursor_next() takes its loop bound from the on-disk nr_entries and element_at() is unguarded pointer arithmetic, so a count larger than the block holds keeps the cursor in one block while the index grows past it and the read walks off the dm-bufio buffer -- dm_cache_load_mappings() drives it once per cache block at activation. Check the header against itself: reject a zero value_size, require max_entries to equal calc_max_entries() for that value_size and block size, and require nr_entries to fit. Equality rather than an upper bound, since a count below the real capacity trips BUG_ON() in fill_ablock() and trim_ablock(). Metadata dm-array writes satisfies all three.

Affected packages

Ecosystem Package Introduced Fixed