CVE-2026-89718: zram: fix out-of-bounds access in writeback_store()
In the Linux kernel, the following vulnerability has been resolved:
zram: fix out-of-bounds access in writebackstore()
Patch series "zram: fix stale scan bounds after reinitialization".
Both writebackstore() and readblockstate() derive their table scan bounds from zram->disksize before acquiring devlock. If the device is reset and reinitialized with a smaller disksize between that read and lock acquisition, the bound can describe the old table while the scan operates on the new one. This can lead to out-of-bounds slot accesses.
Move both bound calculations under devlock so each bound remains consistent with the table throughout its scan. Keep the fixes separate because the affected interfaces originate from different commits and can be backported independently.
This patch (of 2):
writebackstore() calculates the table scan bounds before taking devlock. A reset followed by reconfiguration with a smaller disksize can therefore replace zram->table while writebackstore() is waiting for the lock. Once it acquires the lock, it sees an initialized device but scans the new table using the old upper bound, resulting in an out-of-bounds access.
Calculate the number of pages while holding devlock so the scan bound matches the table protected by the lock.
Affected Software
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Upgrade
Upgrade
zramto a version that resolves this vulnerability.Patch zram: fix stale scan bounds after reinitialization - Upgrade
Upgrade to a fixed release to a version that resolves this vulnerability.
Patch zram: fix out-of-bounds access in writeback_store()
Event History
Frequently Asked Questions
What timing is required for the out-of-bounds access to occur?
writeback_store() must read the device size and then wait to acquire dev_lock. During that interval, the zram device must be reset and reinitialized so that its table is replaced before writeback_store() begins its scan.
Does every zram reconfiguration create this condition?
The described out-of-bounds condition requires reinitialization with a smaller disksize. That makes the previously calculated scan bound larger than the replacement table.
What can be done if the fix cannot be applied immediately?
Avoid allowing writeback_store() activity to overlap with zram reset and reinitialization operations, particularly reconfiguration to a smaller disksize. The fix addresses the race by calculating the scan bound only after dev_lock is held.