GCVE Workshop - 22 September 2026 (14:00-18:00), Luxembourg Before The Vulnopticon Conference - Registration

CVE-2026-89760 (GCVE-0-2026-89760)

Vulnerability from cvelistv5 – Published: 2026-09-11 19:47 – Updated: 2026-09-13 06:34
VLAI
Title
mm, swap: don't free a hibernation slot that is in the swap cache
Summary
In the Linux kernel, the following vulnerability has been resolved: mm, swap: don't free a hibernation slot that is in the swap cache A slot with a folio in the swap cache is freed when the folio leaves the cache, not when its count drops. swap_put_entries_cluster() follows that rule. swap_free_hibernation_slot() does not, it calls __swap_cluster_free_entries() whether or not a folio sits on the slot. Cluster readahead can put one there. It walks a raw page_cluster sized window of offsets around the faulting entry, and a hibernation slot passes __swap_cache_add_check() because it is not a folio and its count is not zero. Freeing the slot then clears the entry under that folio. The folio is now unreachable from the swap table, and the offset goes back to the allocator. The folio is still on the LRU though, so reclaim can pick it up later. It then takes the old offset out of folio->swap and overwrites the table entry there, which by then may belong to someone else. This bug can trigger silent memory corruption, process crashes, or data instability across completely unrelated userspace applications - typically occurring when uswsusp is preparing the hibernation image. I found this while working on giving hibernation slots their own marker in the swap table, which I had discussed with Kairui. (https://lore.kernel.org/linux-mm/abp7aDgYLrxF3Me8@KASONG-MC4/) As far as I know there are no reports, so there is no Reported-by/Closes to add. Check for a cached folio before freeing. The slot is then left in the ordinary state where only the swap cache holds it, and it is freed when the folio leaves the cache, either through the reclaim below or through normal reclaim later.
Severity
7.8 (High)
CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H
Assigner
References
Impacted products
Vendor Product Version CPE status
Linux Linux Affected: 0d6af9bcf383bcdf601e670bb605861b01e318e7 , < a6df73156f2d85746c69adbf13d0f5ea200e0626 (git)
Affected: 0d6af9bcf383bcdf601e670bb605861b01e318e7 , < 10d9012e83efedde8718ceaa5053f836e0c8596c (git)
guessed Create a notification for this product.
Linux Linux Affected: 7.1
Unaffected: 0 , < 7.1 (semver)
Unaffected: 7.2.4 , ≤ 7.2.* (semver)
Unaffected: 7.3-rc1 , ≤ * (original_commit_for_fix)
guessed Create a notification for this product.
Show details on NVD website
To clipboard 

{
  "containers": {
    "cna": {
      "affected": [
        {
          "defaultStatus": "unaffected",
          "product": "Linux",
          "programFiles": [
            "mm/swapfile.c"
          ],
          "repo": "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git",
          "vendor": "Linux",
          "versions": [
            {
              "lessThan": "a6df73156f2d85746c69adbf13d0f5ea200e0626",
              "status": "affected",
              "version": "0d6af9bcf383bcdf601e670bb605861b01e318e7",
              "versionType": "git"
            },
            {
              "lessThan": "10d9012e83efedde8718ceaa5053f836e0c8596c",
              "status": "affected",
              "version": "0d6af9bcf383bcdf601e670bb605861b01e318e7",
              "versionType": "git"
            }
          ]
        },
        {
          "defaultStatus": "affected",
          "product": "Linux",
          "programFiles": [
            "mm/swapfile.c"
          ],
          "repo": "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git",
          "vendor": "Linux",
          "versions": [
            {
              "status": "affected",
              "version": "7.1"
            },
            {
              "lessThan": "7.1",
              "status": "unaffected",
              "version": "0",
              "versionType": "semver"
            },
            {
              "lessThanOrEqual": "7.2.*",
              "status": "unaffected",
              "version": "7.2.4",
              "versionType": "semver"
            },
            {
              "lessThanOrEqual": "*",
              "status": "unaffected",
              "version": "7.3-rc1",
              "versionType": "original_commit_for_fix"
            }
          ]
        }
      ],
      "cpeApplicability": [
        {
          "nodes": [
            {
              "cpeMatch": [
                {
                  "criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
                  "versionEndExcluding": "7.2.4",
                  "versionStartIncluding": "7.1",
                  "vulnerable": true
                },
                {
                  "criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
                  "versionEndExcluding": "7.3-rc1",
                  "versionStartIncluding": "7.1",
                  "vulnerable": true
                }
              ],
              "negate": false,
              "operator": "OR"
            }
          ]
        }
      ],
      "descriptions": [
        {
          "lang": "en",
          "value": "In the Linux kernel, the following vulnerability has been resolved:\n\nmm, swap: don\u0027t free a hibernation slot that is in the swap cache\n\nA slot with a folio in the swap cache is freed when the folio leaves the\ncache, not when its count drops.  swap_put_entries_cluster() follows that\nrule.  swap_free_hibernation_slot() does not, it calls\n__swap_cluster_free_entries() whether or not a folio sits on the slot.\n\nCluster readahead can put one there.  It walks a raw page_cluster sized\nwindow of offsets around the faulting entry, and a hibernation slot passes\n__swap_cache_add_check() because it is not a folio and its count is not\nzero.  Freeing the slot then clears the entry under that folio.\n\nThe folio is now unreachable from the swap table, and the offset goes back\nto the allocator.  The folio is still on the LRU though, so reclaim can\npick it up later.  It then takes the old offset out of folio-\u003eswap and\noverwrites the table entry there, which by then may belong to someone\nelse.\n\nThis bug can trigger silent memory corruption, process crashes, or data\ninstability across completely unrelated userspace applications - typically\noccurring when uswsusp is preparing the hibernation image.\n\nI found this while working on giving hibernation slots their own marker in\nthe swap table, which I had discussed with Kairui. \n(https://lore.kernel.org/linux-mm/abp7aDgYLrxF3Me8@KASONG-MC4/) As far as\nI know there are no reports, so there is no Reported-by/Closes to add.\n\nCheck for a cached folio before freeing.  The slot is then left in the\nordinary state where only the swap cache holds it, and it is freed when\nthe folio leaves the cache, either through the reclaim below or through\nnormal reclaim later."
        }
      ],
      "metrics": [
        {
          "cvssV3_1": {
            "baseScore": 7.8,
            "baseSeverity": "HIGH",
            "vectorString": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H",
            "version": "3.1"
          },
          "scenarios": [
            {
              "lang": "en",
              "value": "AV:L - The bug is reached only through local hibernation swap alloc/free (/dev/snapshot SNAPSHOT_ALLOC_SWAP_PAGE and SNAPSHOT_FREE_SWAP_PAGES, kernel hibernate()/swsusp_write, or swsusp_unmark) racing with local swapin; it is not reachable from network packets or remote protocols.\nAC:L - The attacker controls cluster readahead via tmpfs/shmem swapin (shmem_swapin_cluster always calls swap_cluster_readahead) in the same percpu cluster that swap_alloc_hibernation_slot uses; SNAPSHOT_ALLOC_SWAP_PAGE does not require a freeze, so neighboring hibernation slots can be cached and the sequence retried at will.\nPR:L - The readahead half needs only an ordinary local account (mmap of /dev/shm, pageout, faults). Hibernation is available to a local seat user via logind/polkit or idle/lid policy on typical laptop, desktop, and embedded systems without init-namespace root.\nUI:N - The attacker drives swap activity from their own threads and can start hibernation themselves (logind/systemctl hibernate) or wait for ordinary unattended hibernation; no separate victim action such as mounting a filesystem or opening a file is required.\nS:U - Corruption stays in the host kernel swap table and the same kernel\u0027s anonymous/shmem pages; this is standard local kernel impact, not a VM escape, IOMMU/DMA bypass, or other cross-authority boundary.\nC:H - Freeing a swap-cache folio\u0027s hibernation slot returns that offset to the allocator while the folio remains on the LRU; later reclaim overwrites a reused swap-table entry so another task can be given the stale folio, disclosing hibernation-image or other processes\u0027 memory.\nI:H - The same stale-folio reclaim writes into a swap-table slot that may already hold another folio pointer or swap count, corrupting MM metadata and yielding a kernel write/type-confusion primitive suitable for control-flow hijack rather than a bounded integrity change.\nA:H - The commit documents silent memory corruption and process crashes across unrelated userspace; a reused swap-table entry overwritten with a stale or non-folio value oopses or panics on swapin and can repeatedly crash the system."
            }
          ]
        }
      ],
      "providerMetadata": {
        "dateUpdated": "2026-09-13T06:34:03.885Z",
        "orgId": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
        "shortName": "Linux"
      },
      "references": [
        {
          "url": "https://git.kernel.org/stable/c/a6df73156f2d85746c69adbf13d0f5ea200e0626"
        },
        {
          "url": "https://git.kernel.org/stable/c/10d9012e83efedde8718ceaa5053f836e0c8596c"
        }
      ],
      "title": "mm, swap: don\u0027t free a hibernation slot that is in the swap cache",
      "x_generator": {
        "engine": "bippy-1.2.0"
      }
    }
  },
  "cveMetadata": {
    "assignerOrgId": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
    "assignerShortName": "Linux",
    "cveId": "CVE-2026-89760",
    "datePublished": "2026-09-11T19:47:02.090Z",
    "dateReserved": "2026-09-11T19:38:34.763Z",
    "dateUpdated": "2026-09-13T06:34:03.885Z",
    "state": "PUBLISHED"
  },
  "dataType": "CVE_RECORD",
  "dataVersion": "5.2",
  "vulnerability-lookup:meta": {
    "epss": {
      "cve": "CVE-2026-89760",
      "date": "2026-09-13",
      "epss": "0.00112",
      "percentile": "0.01534"
    },
    "nvd": "{\"cve\":{\"id\":\"CVE-2026-89760\",\"sourceIdentifier\":\"416baaa9-dc9f-4396-8d5f-8c081fb06d67\",\"published\":\"2026-09-11T20:20:07.120\",\"lastModified\":\"2026-09-13T07:17:40.307\",\"vulnStatus\":\"Received\",\"cveTags\":[],\"descriptions\":[{\"lang\":\"en\",\"value\":\"In the Linux kernel, the following vulnerability has been resolved:\\n\\nmm, swap: don\u0027t free a hibernation slot that is in the swap cache\\n\\nA slot with a folio in the swap cache is freed when the folio leaves the\\ncache, not when its count drops.  swap_put_entries_cluster() follows that\\nrule.  swap_free_hibernation_slot() does not, it calls\\n__swap_cluster_free_entries() whether or not a folio sits on the slot.\\n\\nCluster readahead can put one there.  It walks a raw page_cluster sized\\nwindow of offsets around the faulting entry, and a hibernation slot passes\\n__swap_cache_add_check() because it is not a folio and its count is not\\nzero.  Freeing the slot then clears the entry under that folio.\\n\\nThe folio is now unreachable from the swap table, and the offset goes back\\nto the allocator.  The folio is still on the LRU though, so reclaim can\\npick it up later.  It then takes the old offset out of folio-\u003eswap and\\noverwrites the table entry there, which by then may belong to someone\\nelse.\\n\\nThis bug can trigger silent memory corruption, process crashes, or data\\ninstability across completely unrelated userspace applications - typically\\noccurring when uswsusp is preparing the hibernation image.\\n\\nI found this while working on giving hibernation slots their own marker in\\nthe swap table, which I had discussed with Kairui. \\n(https://lore.kernel.org/linux-mm/abp7aDgYLrxF3Me8@KASONG-MC4/) As far as\\nI know there are no reports, so there is no Reported-by/Closes to add.\\n\\nCheck for a cached folio before freeing.  The slot is then left in the\\nordinary state where only the swap cache holds it, and it is freed when\\nthe folio leaves the cache, either through the reclaim below or through\\nnormal reclaim later.\"}],\"affected\":[{\"source\":\"416baaa9-dc9f-4396-8d5f-8c081fb06d67\",\"affectedData\":[{\"vendor\":\"Linux\",\"product\":\"Linux\",\"defaultStatus\":\"unaffected\",\"programFiles\":[\"mm/swapfile.c\"],\"repo\":\"https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git\",\"versions\":[{\"version\":\"0d6af9bcf383bcdf601e670bb605861b01e318e7\",\"lessThan\":\"a6df73156f2d85746c69adbf13d0f5ea200e0626\",\"versionType\":\"git\",\"status\":\"affected\"},{\"version\":\"0d6af9bcf383bcdf601e670bb605861b01e318e7\",\"lessThan\":\"10d9012e83efedde8718ceaa5053f836e0c8596c\",\"versionType\":\"git\",\"status\":\"affected\"}]},{\"vendor\":\"Linux\",\"product\":\"Linux\",\"defaultStatus\":\"affected\",\"programFiles\":[\"mm/swapfile.c\"],\"repo\":\"https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git\",\"versions\":[{\"version\":\"7.1\",\"status\":\"affected\"},{\"version\":\"0\",\"lessThan\":\"7.1\",\"versionType\":\"semver\",\"status\":\"unaffected\"},{\"version\":\"7.2.4\",\"lessThanOrEqual\":\"7.2.*\",\"versionType\":\"semver\",\"status\":\"unaffected\"},{\"version\":\"7.3-rc1\",\"lessThanOrEqual\":\"*\",\"versionType\":\"original_commit_for_fix\",\"status\":\"unaffected\"}]}]}],\"metrics\":{\"cvssMetricV31\":[{\"source\":\"416baaa9-dc9f-4396-8d5f-8c081fb06d67\",\"type\":\"Secondary\",\"cvssData\":{\"version\":\"3.1\",\"vectorString\":\"CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H\",\"baseScore\":7.8,\"baseSeverity\":\"HIGH\",\"attackVector\":\"LOCAL\",\"attackComplexity\":\"LOW\",\"privilegesRequired\":\"LOW\",\"userInteraction\":\"NONE\",\"scope\":\"UNCHANGED\",\"confidentialityImpact\":\"HIGH\",\"integrityImpact\":\"HIGH\",\"availabilityImpact\":\"HIGH\"},\"exploitabilityScore\":1.8,\"impactScore\":5.9}]},\"references\":[{\"url\":\"https://git.kernel.org/stable/c/10d9012e83efedde8718ceaa5053f836e0c8596c\",\"source\":\"416baaa9-dc9f-4396-8d5f-8c081fb06d67\"},{\"url\":\"https://git.kernel.org/stable/c/a6df73156f2d85746c69adbf13d0f5ea200e0626\",\"source\":\"416baaa9-dc9f-4396-8d5f-8c081fb06d67\"}]}}",
    "redhat_vex": {
      "aggregate_severity": "Moderate",
      "current_release_date": "2026-09-13T06:52:50+00:00",
      "cve": "CVE-2026-89760",
      "id": "CVE-2026-89760",
      "initial_release_date": "2026-09-11T19:47:02.090000+00:00",
      "product_status:known_affected": "2",
      "source": "Red Hat CSAF VEX",
      "status": "final",
      "title": "kernel: Linux Kernel: Memory corruption due to improper handling of hibernation slots in swap cache",
      "url": "https://security.access.redhat.com/data/csaf/v2/vex/2026/cve-2026-89760.json",
      "version": "3"
    }
  }
}



Log in or create an account to share your comment.




Tags
Taxonomy of the tags.





Forecast uses a logistic model when the trend is rising, or an exponential decay model when the trend is falling. Fitted via linearized least squares.

Sightings

Author Source Type Date Other

Nomenclature

  • Seen: The vulnerability was mentioned, discussed, or observed by the user.
  • Confirmed: The vulnerability has been validated from an analyst's perspective.
  • Published Proof of Concept: A public proof of concept is available for this vulnerability.
  • Exploited: The vulnerability was observed as exploited by the user who reported the sighting.
  • Patched: The vulnerability was observed as successfully patched by the user who reported the sighting.
  • Not exploited: The vulnerability was not observed as exploited by the user who reported the sighting.
  • Not confirmed: The user expressed doubt about the validity of the vulnerability.
  • Not patched: The vulnerability was not observed as successfully patched by the user who reported the sighting.


Detection rules are retrieved from Rulezet.