CVE-2026-89718: Linux Kernel zram Use-After-Free Vulnerability

CVE-2026-89718 Overview

CVE-2026-89718 is an out-of-bounds access vulnerability in the Linux kernel's zram compressed block device driver. The flaw resides in writeback_store(), which calculates table scan bounds from zram->disksize before acquiring dev_lock. If the device is reset and reinitialized with a smaller disksize between the bound calculation and lock acquisition, the scan operates on the new table using the old upper bound. This produces out-of-bounds slot accesses against the reinitialized zram->table.

Critical Impact
Local processes with access to zram sysfs interfaces can trigger out-of-bounds memory access by racing device reconfiguration with writeback operations, potentially causing kernel memory corruption or denial of service.

Affected Products

Linux kernel versions containing the zramwriteback_store() interface prior to the fix commits
Distributions shipping affected stable kernel branches
Systems using zram for swap or compressed block storage

Discovery Timeline

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

Technical Details for CVE-2026-89718

Vulnerability Analysis

The zram driver exposes a writeback sysfs interface that iterates over slots in the internal zram->table to migrate compressed pages to a backing device. The writeback_store() function derives the scan upper bound from zram->disksize before it acquires dev_lock. A concurrent reset via the reset sysfs attribute can free the existing table and reinitialize the device with a smaller disksize. When writeback_store() finally acquires dev_lock, it observes an initialized device but continues to use the stale, larger bound while walking the newly allocated table.

The result is indexing beyond the allocated slot array, an out-of-bounds read or write against kernel memory belonging to unrelated allocations. A companion patch addresses the same class of stale-bound issue in read_block_state(), indicating the pattern was present in more than one zram control path.

Root Cause

The root cause is a time-of-check to time-of-use (TOCTOU) race between reading zram->disksize and acquiring dev_lock. Bound calculation and table access are not performed under a single consistent lock scope. This allows the table pointer and its length to diverge from the value used to constrain iteration.

Attack Vector

Exploitation requires local access to the zram sysfs control files, typically restricted to privileged users. An attacker with the ability to write to /sys/block/zram*/reset, /sys/block/zram*/disksize, and /sys/block/zram*/writeback can race a reconfiguration against an in-flight writeback to trigger the out-of-bounds access. The vulnerability affects kernel memory safety and does not require network reachability. Refer to the upstream commits for the exact code paths and remediation logic.

Detection Methods for CVE-2026-89718

Indicators of Compromise

Kernel oops or panic messages referencing writeback_store or zram in call stacks
KASAN slab-out-of-bounds reports naming zram->table or zram_slot structures
Unexpected zram device resets correlated with writeback activity in system logs

Detection Strategies

Enable KASAN (Kernel Address Sanitizer) on test kernels to surface out-of-bounds slot accesses in zram code paths
Audit process activity that writes concurrently to zram sysfs attributes reset, disksize, and writeback
Correlate kernel log entries from dmesg containing zram warnings with local user session activity

Monitoring Recommendations

Ingest /var/log/kern.log and journalctl -k output into a centralized log platform and alert on zram fault signatures
Track sysfs write events on /sys/block/zram* using auditd rules to identify unusual reconfiguration patterns
Monitor kernel version inventory across Linux fleets to identify hosts still running unpatched stable branches

How to Mitigate CVE-2026-89718

Immediate Actions Required

Apply the upstream Linux kernel patches referenced by commits 07a82a66 and 894913e2
Update to distribution kernel packages that include the zram stale scan bounds fix
Restrict write access to zram sysfs attributes to trusted administrative accounts only

Patch Information

The fix moves the page-count calculation inside the dev_lock critical section in writeback_store(), ensuring the scan bound matches the zram->table protected by the same lock. A companion commit applies the equivalent change to read_block_state(). Both commits are available in the upstream stable tree and are suitable for independent backport. See the Kernel Git Commit 07a82a66 and Kernel Git Commit 894913e2 for the authoritative patches.

Workarounds

Disable the zram module on systems that do not require compressed swap using modprobe -r zram and blacklist the module
Remove or restrict permissions on /sys/block/zram*/reset and /sys/block/zram*/writeback to prevent unprivileged reconfiguration
Avoid concurrent orchestration workflows that reset and write back zram devices in overlapping windows

bash

# Configuration example: prevent zram module load and restrict sysfs access
echo 'blacklist zram' | sudo tee /etc/modprobe.d/disable-zram.conf
sudo modprobe -r zram 2>/dev/null || true

# If zram is required, tighten sysfs permissions
sudo chmod 600 /sys/block/zram0/reset /sys/block/zram0/writeback /sys/block/zram0/disksize