Cloudanix VulnDB

CVE-2026-89719

None

CVSS

—

EPSS

0.2%

Published

Sep 11, 2026

CISA due date

—

Cloudanix analysis

Schedule a fix SSVC: Track

A bug in the Linux kernel's compressed memory feature can let an attacker on the same machine crash the whole system by resetting the memory device at the wrong moment.

Exploitation
Local Privilege
Attacker needs
Local User
Complexity
Moderate
Impact
Data Exposure
Component
OS kernel
Class
Buffer Overflow
Remediation
Patch
Effort
Medium
Patch risk
Low

What it actually does

Race condition in zram read_block_state allows out-of-bounds slot_lock access when nr_pages is computed before dev_lock and a concurrent reset shrinks the table.

Why it matters to the business

Linux systems using zram for compressed swap or ramdisks can experience kernel crashes or memory corruption, causing downtime and potential data loss in production workloads.

How an attack unfolds

An attacker with local access triggers repeated zram device reset and reinitialization to a smaller size while a concurrent read_block_state scan is in progress, causing the stale nr_pages value to index past the new table bounds.

How to fix it

Apply the upstream zram fix that moves disksize read after dev_lock acquisition and initialization check; rebuild and deploy the patched kernel across all affected systems.

How to confirm the fix worked

Confirm the fix is present by inspecting the read_block_state implementation for the updated locking sequence; test by exercising zram reset under concurrent read_block_state load.

Typical attack path

  1. Obtain local shell on target Linux system
  2. Repeatedly reset and resize zram device to trigger table reallocation
  3. Race with kernel read_block_state to induce out-of-bounds access
  4. Escalate resulting kernel fault into denial of service or memory corruption

How to detect it

Search kernel logs for oops or BUG messages referencing read_block_state, slot_lock, or zram table bounds; correlate with zram device reset events in dmesg or audit logs.

What your security team should do

  • Prioritize kernel updates on all systems using zram for swap or block devices
  • Monitor for zram-related kernel oops or panics in production logs
  • Restrict unprivileged local access where zram reconfiguration is possible

The record

In the Linux kernel, the following vulnerability has been resolved: zram: fix out-of-bounds access in read_block_state() read_block_state() calculates nr_pages before taking dev_lock. If the device is reset and reinitialized with a smaller disksize before lock acquisition, nr_pages still describes the old table. The subsequent loop can then call slot_lock() past the end of the newly allocated table. Read disksize after acquiring dev_lock and checking that the device is initialized. The read lock then keeps the table and its bound stable for the duration of the scan.

Affected packages

Ecosystem Package Introduced Fixed