VulnerabilityPublished 11 Sep 2026Updated 21 Oct 2026

CVE-2026-89718: Linux kernel · zram: fix out-of-bounds access in writeback_store()

Affects Linux kernelSource CVE Database V5

Not known to be exploited · fixed in ef073edd7cfd31aeb90eeab23273102c601f4d8e : update Linux kernel when convenient.

Data as of 26 Oct 2026, 13:47 UTC

Severity

Unrated

Rated by Threat Radar · CVSS not yet scored by NVD

EPSS: 0.1% chance of exploitation in 30 days – higher than 6% of CVEsExploit Prediction Scoring System: the likelihood attackers will use this flaw soon.
Patch: Available – fixed in ef073edd7cfd31aeb90eeab23273102c601f4d8e, c2745e657f0974871fbc60d46d48c2b04e581330, 894913e2d35c46ff19a77530907771ae57862b96 +2

Exploitation evidence

Disclosed: evidence found.
CVE published 11 Sep 2026
Detectable: no evidence on record.
No public nuclei template indexed
Weaponised: no evidence on record.
No public exploit code indexed in Metasploit or Exploit-DB
Exploited in the wildExploited: no evidence on record.
Not in CISA KEV and no source reports exploitation
Observed by OffSeq MirageSeen by Mirage: no evidence on record.
No attack traffic recorded by OffSeq Mirage sensors

A missing step is not evidence of safety. Sources: cve.org (opens in a new tab), the Metasploit, Exploit-DB and nuclei-templates index as of 26 Oct 2026.

Disclosed: The CVE record is public on cve.org. Its publication is t = 0.
Detectable: A public nuclei template can find exposed instances, for defenders and attackers alike.
Weaponised: Public exploit code exists in Metasploit or Exploit-DB, or CISA SSVC or the CVSS exploit maturity reports a public proof of concept.
Exploited in the wild: CISA KEV lists it, CISA SSVC rates exploitation active, or a source reports attacks.
Observed by OffSeq Mirage: OffSeq Mirage honeypot sensors recorded attack traffic for this CVE, or found exposed hosts without attack traffic.

Moments are spaced evenly, not to scale; a dashed line marks a gap of six months or more. Deltas count from t = 0. Sources that give only a date (CISA KEV, Exploit-DB, or a time of exactly 00:00Z) read “same day” rather than hours. Metasploit modules carry the flaw’s disclosure date, not their release date, and nuclei templates carry no date, so both appear above but not on the timeline.

What to do

Upgrade to a fixed release listed under Affected software.

Affected software

Product	Affected	Fixed in
LinuxLinux	Affected ≥ a939888ec38bf1f33e4a903056677e92a4844244, < ef073edd7cfd31aeb90eeab23273102c601f4d8e	Fixed in ef073edd7cfd31aeb90eeab23273102c601f4d8e
LinuxLinux	Affected ≥ a939888ec38bf1f33e4a903056677e92a4844244, < c2745e657f0974871fbc60d46d48c2b04e581330	Fixed in c2745e657f0974871fbc60d46d48c2b04e581330
LinuxLinux	Affected ≥ a939888ec38bf1f33e4a903056677e92a4844244, < 894913e2d35c46ff19a77530907771ae57862b96	Fixed in 894913e2d35c46ff19a77530907771ae57862b96
LinuxLinux	Affected ≥ a939888ec38bf1f33e4a903056677e92a4844244, < 07a82a66f8c1894d92e51d97542c32ebf2c51b09	Fixed in 07a82a66f8c1894d92e51d97542c32ebf2c51b09
LinuxLinux	Affected ≥ a939888ec38bf1f33e4a903056677e92a4844244, < 4d82d60178b02797dbe529e01ac211b26670c49f	Fixed in 4d82d60178b02797dbe529e01ac211b26670c49f
LinuxLinux	Affected =5.0	Fixed in–

Description

In the Linux kernel, the following vulnerability has been resolved: zram: fix out-of-bounds access in writeback_store() Patch series "zram: fix stale scan bounds after reinitialization". Both writeback_store() and read_block_state() derive their table scan bounds from zram->disksize before acquiring dev_lock. 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 dev_lock 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): writeback_store() calculates the table scan bounds before taking dev_lock. A reset followed by reconfiguration with a smaller disksize can therefore replace zram->table while writeback_store() 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 dev_lock so the scan bound matches the table protected by the lock.

References

Community reviews

Loading reviews…