{
  "affected": [
    {
      "ranges": [
        {
          "events": [
            {
              "introduced": "a939888ec38bf1f33e4a903056677e92a4844244"
            },
            {
              "fixed": "07a82a66f8c1894d92e51d97542c32ebf2c51b09"
            },
            {
              "fixed": "894913e2d35c46ff19a77530907771ae57862b96"
            }
          ],
          "repo": "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git",
          "type": "GIT"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "Linux",
        "name": "Kernel"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "5.0.0"
            },
            {
              "fixed": "7.2.4"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "database_specific": {
    "cna_assigner": "Linux",
    "osv_generated_from": "https://github.com/CVEProject/cvelistV5/tree/main/cves/2026/89xxx/CVE-2026-89718.json"
  },
  "details": "In the Linux kernel, the following vulnerability has been resolved:\n\nzram: fix out-of-bounds access in writeback_store()\n\nPatch series \"zram: fix stale scan bounds after reinitialization\".\n\nBoth writeback_store() and read_block_state() derive their table scan\nbounds from zram-\u003edisksize before acquiring dev_lock.  If the device is\nreset and reinitialized with a smaller disksize between that read and lock\nacquisition, the bound can describe the old table while the scan operates\non the new one.  This can lead to out-of-bounds slot accesses.\n\nMove both bound calculations under dev_lock so each bound remains\nconsistent with the table throughout its scan.  Keep the fixes separate\nbecause the affected interfaces originate from different commits and can\nbe backported independently.\n\n\nThis patch (of 2):\n\nwriteback_store() calculates the table scan bounds before taking dev_lock.\nA reset followed by reconfiguration with a smaller disksize can therefore\nreplace zram-\u003etable while writeback_store() is waiting for the lock.  Once\nit acquires the lock, it sees an initialized device but scans the new\ntable using the old upper bound, resulting in an out-of-bounds access.\n\nCalculate the number of pages while holding dev_lock so the scan bound\nmatches the table protected by the lock.",
  "id": "CVE-2026-89718",
  "modified": "2026-09-13T03:30:31.695913765Z",
  "published": "2026-09-11T19:46:31.443Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/07a82a66f8c1894d92e51d97542c32ebf2c51b09"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/894913e2d35c46ff19a77530907771ae57862b96"
    },
    {
      "type": "ADVISORY",
      "url": "https://github.com/CVEProject/cvelistV5/tree/main/cves/2026/89xxx/CVE-2026-89718.json"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-89718"
    },
    {
      "type": "PACKAGE",
      "url": "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git"
    }
  ],
  "schema_version": "1.9.0",
  "summary": "zram: fix out-of-bounds access in writeback_store()"
}