Vulnerability-Lookup

GHSA-JF6F-8M48-J65R

Vulnerability from github – Published: 2026-09-11 21:31 – Updated: 2026-09-13 09:32

Details

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

Show details on source website

JSON

To clipboard

{
  "affected": [],
  "aliases": [
    "CVE-2026-89760"
  ],
  "database_specific": {
    "cwe_ids": [],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2026-09-11T20:20:07Z",
    "severity": "HIGH"
  },
  "details": "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.",
  "id": "GHSA-jf6f-8m48-j65r",
  "modified": "2026-09-13T09:32:30Z",
  "published": "2026-09-11T21:31:39Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-89760"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/10d9012e83efedde8718ceaa5053f836e0c8596c"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/a6df73156f2d85746c69adbf13d0f5ea200e0626"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H",
      "type": "CVSS_V3"
    }
  ]
}

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

Vulnerability from cvelistv5 – Published: 2026-09-11 19:47 – Updated: 2026-10-19 08:52

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

Linux CNA under the mitre root

CNA scorecard D 53/100 over 6643 records in the last 180 days details

References

2 references

URL	Tags
https://git.kernel.org/stable/c/a6df73156f2d85746…
https://git.kernel.org/stable/c/10d9012e83efedde8…

Impacted products

2 products

Vendor	Product	Version
Linux	Linux	Affected: 0d6af9bcf383bcdf601e670bb605861b01e318e7 , < a6df73156f2d85746c69adbf13d0f5ea200e0626 (git) Affected: 0d6af9bcf383bcdf601e670bb605861b01e318e7 , < 10d9012e83efedde8718ceaa5053f836e0c8596c (git)
Linux	Linux	Affected: 7.1 Unaffected: 0 , < 7.1 (semver) Unaffected: 7.2.4 , ≤ 7.2.* (semver) Unaffected: 7.3 , ≤ * (original_commit_for_fix)

Show details on NVD website

JSON

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",
              "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",
                  "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-10-19T08:52:13.808Z",
        "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-10-19T08:52:13.808Z",
    "state": "PUBLISHED"
  },
  "dataType": "CVE_RECORD",
  "dataVersion": "5.2"
}

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.

Vulnerability timeline

Sightings and recorded dates, grouped by day · UTC

Order JSON

How durations are calculated

Following the VTEM framework (Black Hat USA 2015), time to patch starts when the vendor or a coordinator was informed, total time to patch at discovery, and disclosure to patch at public disclosure; vendor response time runs from the report to its acknowledgement. Time to exploit and time unpatched start at the earliest discovery or report, falling back to public disclosure. Unpatched time ends at the first recorded patch, or the calculation time when no patch is recorded. Exploitation to patch shows the interval between those two events; a published proof of concept is a public exploit, not exploitation.

Each result shows its source dates. A negative interval means the end event came first; when date-only inputs leave the order open, the result says so. Date-only inputs are approximate. The earliest evidence wins: KEV report dates and sightings are labelled as such. Records describing another vulnerability are listed but never calculated from, and a PoC alone does not establish exploitation. Missing patch evidence does not prove that no patch exists. Filters below change the event list only.

Publication & reservation Sightings KEV catalogs Other timestamps

Loading timeline…

The MITRE ATT&CK techniques below are AI-generated suggestions, inferred from the description of the vulnerability by the CIRCL/vulnerability-attack-technique-classification-roberta-base model, served locally by ML-Gateway. They have not been verified by an analyst and are provided for guidance only.
The approach is described in our paper Mapping CVEs to MITRE ATT&CK Techniques: A Curated Gold-Set Classifier and the Limits of LLM-Assisted Label Expansion.
Browse all ATT&CK techniques and the vulnerabilities related to each.

Related by attack behaviour

Vulnerabilities whose description is nearest to this one in the vector space of the CIRCL/vulnerability-attack-technique-biencoder model. This is a similarity search over the bi-encoder space (plain cosine), not a classification, and it has no measured accuracy.

Action not permitted