CVE-2026-89719: Linux Kernel zram Privilege Escalation

CVE-2026-89719 Overview

CVE-2026-89719 is an out-of-bounds access vulnerability in the Linux kernel's zram compressed block device driver. The flaw resides in the read_block_state() function, which calculates nr_pages before acquiring dev_lock. If the zram device is reset and reinitialized with a smaller disksize between the calculation and lock acquisition, the stale nr_pages value causes the subsequent loop to invoke slot_lock() beyond the bounds of the newly allocated table. The upstream fix moves the disksize read to occur after dev_lock acquisition and after verifying the device is initialized.

Critical Impact
A local user with access to zram debug interfaces can trigger an out-of-bounds memory access in kernel space, potentially leading to kernel memory corruption or a denial-of-service condition.

Affected Products

Linux kernel with the zram block device driver enabled
Distributions shipping kernels prior to the referenced stable commits
Systems exposing zram block_state debugfs interfaces to unprivileged access paths

Discovery Timeline

2026-09-11 - CVE-2026-89719 published to NVD
2026-09-11 - Last updated in NVD database

Technical Details for CVE-2026-89719

Vulnerability Analysis

The zram driver in the Linux kernel provides compressed RAM-based block devices, commonly used for swap and temporary storage. The read_block_state() function exposes per-slot state information through debugfs. It iterates across every page slot in the device's internal table.

The defect is a time-of-check to time-of-use (TOCTOU) race. The function reads disksize and derives nr_pages from it before taking dev_lock. Between that calculation and lock acquisition, another thread can reset the device and reinitialize it with a smaller disksize. The reinitialization reallocates the slot table at a smaller size. When read_block_state() finally proceeds under the lock, it iterates using the stale nr_pages, calling slot_lock() on indices past the end of the freshly allocated table.

Root Cause

The root cause is unsynchronized access to the disksize field. The size determining loop bounds was read outside of dev_lock, violating the invariant that table geometry and its backing allocation must be observed atomically. The fix reads disksize after acquiring dev_lock and confirming device initialization, so the read lock keeps both the table pointer and its bounds stable for the entire scan.

Attack Vector

Exploitation requires local access and the ability to interact with zram debugfs entries while concurrently issuing device reset and reinitialization operations. An attacker with the necessary privileges can race a reader of block_state against a shrinking reinitialization to trigger an out-of-bounds slot_lock() call. The resulting memory access can corrupt adjacent kernel data structures or crash the kernel, depending on allocator layout.

See the upstream commits for the exact code changes: Kernel Git Commit 391f057, Kernel Git Commit 5e458fa, and Kernel Git Commit e7dbcb7.

Detection Methods for CVE-2026-89719

Indicators of Compromise

Kernel oops or panic messages referencing read_block_state, slot_lock, or zram in dmesg output
KASAN reports flagging out-of-bounds access within the zram module
Unexpected zram device resets correlated with debugfs block_state reads

Detection Strategies

Monitor /sys/kernel/debug/zram*/block_state access patterns and correlate with reset and disksize writes on the same device
Enable KASAN on test kernels to surface the out-of-bounds access during regression testing
Audit kernel version strings across the fleet against the fixed stable commits

Monitoring Recommendations

Ingest kernel crash logs and dmesg into a centralized log platform to identify zram-related faults
Alert on repeated zram device reinitialization events from non-administrative processes
Track process access to /sys/block/zram* and debugfs zram paths

How to Mitigate CVE-2026-89719

Immediate Actions Required

Apply the upstream stable kernel patches referenced in commits 391f057, 5e458fa, and e7dbcb7
Update to a distribution kernel that incorporates the read_block_state() locking fix
Restrict access to zram debugfs interfaces to trusted administrators only

Patch Information

The fix is available in the mainline and stable Linux kernel trees. It relocates the disksize read inside the dev_lock critical section and gates it on a device-initialized check. Refer to Kernel Git Commit 391f057, Kernel Git Commit 5e458fa, and Kernel Git Commit e7dbcb7 for the authoritative patches.

Workarounds

Unmount and disable the zram module (modprobe -r zram) on systems that do not require compressed block devices
Remount debugfs with restricted permissions or disable it entirely where operationally acceptable
Limit which local users can trigger zram reset and disksize changes via udev rules and filesystem permissions on /sys/block/zram*

bash

# Restrict debugfs access to root only until patched kernel is deployed
mount -o remount,mode=700 /sys/kernel/debug

# Optionally unload zram if not required
swapoff /dev/zram0 2>/dev/null
modprobe -r zram