Vulnerability-Lookup

GHSA-RW23-9H76-PF6X

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/mempolicy: skip non-present PMDs when queueing folios

Patch series "mm: handle device-private PMDs in walk callbacks", v3.

Since commit 368076f52ebe ("mm/huge_memory: add device-private THP support to PMD operations") a PMD may hold a device-private swap entry whenever an HMM-based GPU driver migrates an anonymous THP folio to device memory via migrate_vma_pages().

pmd_trans_huge_lock() succeeds for such PMDs (pmd_is_huge() returns true for any non-present, non-none huge PMD), so several MM walk callbacks that used to assume present THP or migration entry are now reachable with a device-private PMD. The results range from a VM_BUG_ON() firing on debug kernels, to an oops on a bogus vmemmap dereference, to silently isolating an unrelated live folio from LRU in the aliasing case.

This patch (of 3):

queue_folios_pmd() is called under pmd_trans_huge_lock(), whose pmd_is_huge() check returns true for any non-present, non-none PMD softleaf. Passing such a PMD to pmd_folio() treats the softleaf encoding as a hardware PFN and can return a bogus folio pointer.

Mirror queue_folios_pte_range(): handle non-present entries before looking up a folio. Keep migration entries counted as failures, but skip other non-present PMDs such as device-private entries.

Potential trigger: an HMM-based GPU driver migrates an anonymous THP folio to device memory via migrate_vma_pages(), leaving a device-private PMD. Userspace then calls mbind(), migrate_pages() or set_mempolicy_home_node() on that range.

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-89758"
  ],
  "database_specific": {
    "cwe_ids": [],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2026-09-11T20:20:06Z",
    "severity": "HIGH"
  },
  "details": "In the Linux kernel, the following vulnerability has been resolved:\n\nmm/mempolicy: skip non-present PMDs when queueing folios\n\nPatch series \"mm: handle device-private PMDs in walk callbacks\", v3.\n\nSince commit 368076f52ebe (\"mm/huge_memory: add device-private THP support\nto PMD operations\") a PMD may hold a device-private swap entry whenever an\nHMM-based GPU driver migrates an anonymous THP folio to device memory via\nmigrate_vma_pages().\n\npmd_trans_huge_lock() succeeds for such PMDs (pmd_is_huge() returns true\nfor any non-present, non-none huge PMD), so several MM walk callbacks that\nused to assume present THP or migration entry are now reachable with a\ndevice-private PMD.  The results range from a VM_BUG_ON() firing on debug\nkernels, to an oops on a bogus vmemmap dereference, to silently isolating\nan unrelated live folio from LRU in the aliasing case.\n\n\nThis patch (of 3):\n\nqueue_folios_pmd() is called under pmd_trans_huge_lock(), whose\npmd_is_huge() check returns true for any non-present, non-none PMD\nsoftleaf.  Passing such a PMD to pmd_folio() treats the softleaf encoding\nas a hardware PFN and can return a bogus folio pointer.\n\nMirror queue_folios_pte_range(): handle non-present entries before looking\nup a folio.  Keep migration entries counted as failures, but skip other\nnon-present PMDs such as device-private entries.\n\nPotential trigger: an HMM-based GPU driver migrates an anonymous THP folio\nto device memory via migrate_vma_pages(), leaving a device-private PMD. \nUserspace then calls mbind(), migrate_pages() or set_mempolicy_home_node()\non that range.",
  "id": "GHSA-rw23-9h76-pf6x",
  "modified": "2026-09-13T09:32:30Z",
  "published": "2026-09-11T21:31:39Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-89758"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/2858b4027f491e6fdb8ee2d8923798b619bf2791"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/3d927093b2add7ced588a926c3dc5d7a83f18596"
    }
  ],
  "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-89758 (GCVE-0-2026-89758)

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

Title

mm/mempolicy: skip non-present PMDs when queueing folios

Summary

In the Linux kernel, the following vulnerability has been resolved: mm/mempolicy: skip non-present PMDs when queueing folios Patch series "mm: handle device-private PMDs in walk callbacks", v3. Since commit 368076f52ebe ("mm/huge_memory: add device-private THP support to PMD operations") a PMD may hold a device-private swap entry whenever an HMM-based GPU driver migrates an anonymous THP folio to device memory via migrate_vma_pages(). pmd_trans_huge_lock() succeeds for such PMDs (pmd_is_huge() returns true for any non-present, non-none huge PMD), so several MM walk callbacks that used to assume present THP or migration entry are now reachable with a device-private PMD. The results range from a VM_BUG_ON() firing on debug kernels, to an oops on a bogus vmemmap dereference, to silently isolating an unrelated live folio from LRU in the aliasing case. This patch (of 3): queue_folios_pmd() is called under pmd_trans_huge_lock(), whose pmd_is_huge() check returns true for any non-present, non-none PMD softleaf. Passing such a PMD to pmd_folio() treats the softleaf encoding as a hardware PFN and can return a bogus folio pointer. Mirror queue_folios_pte_range(): handle non-present entries before looking up a folio. Keep migration entries counted as failures, but skip other non-present PMDs such as device-private entries. Potential trigger: an HMM-based GPU driver migrates an anonymous THP folio to device memory via migrate_vma_pages(), leaving a device-private PMD. Userspace then calls mbind(), migrate_pages() or set_mempolicy_home_node() on that range.

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 6639 records in the last 180 days details

References

2 references

URL	Tags
https://git.kernel.org/stable/c/3d927093b2add7ced…
https://git.kernel.org/stable/c/2858b4027f491e6fd…

Impacted products

2 products

Vendor	Product	Version
Linux	Linux	Affected: 368076f52ebeecd33e10a9f80905d7508b6b6149 , < 3d927093b2add7ced588a926c3dc5d7a83f18596 (git) Affected: 368076f52ebeecd33e10a9f80905d7508b6b6149 , < 2858b4027f491e6fdb8ee2d8923798b619bf2791 (git)
Linux	Linux	Affected: 6.19 Unaffected: 0 , < 6.19 (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/mempolicy.c"
          ],
          "repo": "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git",
          "vendor": "Linux",
          "versions": [
            {
              "lessThan": "3d927093b2add7ced588a926c3dc5d7a83f18596",
              "status": "affected",
              "version": "368076f52ebeecd33e10a9f80905d7508b6b6149",
              "versionType": "git"
            },
            {
              "lessThan": "2858b4027f491e6fdb8ee2d8923798b619bf2791",
              "status": "affected",
              "version": "368076f52ebeecd33e10a9f80905d7508b6b6149",
              "versionType": "git"
            }
          ]
        },
        {
          "defaultStatus": "affected",
          "product": "Linux",
          "programFiles": [
            "mm/mempolicy.c"
          ],
          "repo": "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git",
          "vendor": "Linux",
          "versions": [
            {
              "status": "affected",
              "version": "6.19"
            },
            {
              "lessThan": "6.19",
              "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": "6.19",
                  "vulnerable": true
                },
                {
                  "criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
                  "versionEndExcluding": "7.3",
                  "versionStartIncluding": "6.19",
                  "vulnerable": true
                }
              ],
              "negate": false,
              "operator": "OR"
            }
          ]
        }
      ],
      "descriptions": [
        {
          "lang": "en",
          "value": "In the Linux kernel, the following vulnerability has been resolved:\n\nmm/mempolicy: skip non-present PMDs when queueing folios\n\nPatch series \"mm: handle device-private PMDs in walk callbacks\", v3.\n\nSince commit 368076f52ebe (\"mm/huge_memory: add device-private THP support\nto PMD operations\") a PMD may hold a device-private swap entry whenever an\nHMM-based GPU driver migrates an anonymous THP folio to device memory via\nmigrate_vma_pages().\n\npmd_trans_huge_lock() succeeds for such PMDs (pmd_is_huge() returns true\nfor any non-present, non-none huge PMD), so several MM walk callbacks that\nused to assume present THP or migration entry are now reachable with a\ndevice-private PMD.  The results range from a VM_BUG_ON() firing on debug\nkernels, to an oops on a bogus vmemmap dereference, to silently isolating\nan unrelated live folio from LRU in the aliasing case.\n\n\nThis patch (of 3):\n\nqueue_folios_pmd() is called under pmd_trans_huge_lock(), whose\npmd_is_huge() check returns true for any non-present, non-none PMD\nsoftleaf.  Passing such a PMD to pmd_folio() treats the softleaf encoding\nas a hardware PFN and can return a bogus folio pointer.\n\nMirror queue_folios_pte_range(): handle non-present entries before looking\nup a folio.  Keep migration entries counted as failures, but skip other\nnon-present PMDs such as device-private entries.\n\nPotential trigger: an HMM-based GPU driver migrates an anonymous THP folio\nto device memory via migrate_vma_pages(), leaving a device-private PMD. \nUserspace then calls mbind(), migrate_pages() or set_mempolicy_home_node()\non that range."
        }
      ],
      "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 - queue_folios_pmd() is reached only from local mbind() and migrate_pages() via do_mbind()/do_migrate_pages() -\u003e queue_pages_range() -\u003e walk_page_range(); it is not a network, Bluetooth, or USB packet path.\nAC:L - An attacker with GPU/HMM access can deterministically migrate an anonymous THP to device memory (leaving a device-private PMD) and then call mbind()/migrate_pages() on that range; no victim state or attacker-uncontrollable race is required.\nPR:L - mbind() and self migrate_pages() are unprivileged; MPOL_MF_MOVE needs no capability. Device-private THP is created through ordinary DRM render-node/HMM usage (AMD KFD, Intel Xe, nouveau), not init-namespace root.\nUI:N - The attacker creates the device-private THP mapping and issues mbind() or migrate_pages() entirely in their own process; no other user must mount, open, or otherwise act.\nS:U - Impact is host-kernel MM corruption (bogus folio lookup and LRU isolation) within the same security authority; it is not a VM guest-to-host escape, IOMMU bypass, or sandbox breakout.\nC:H - pmd_folio() treats a device-private PMD as a present THP and returns a bogus folio; aliasing isolates and migrates an unrelated live folio, a memory-corruption primitive usable for arbitrary kernel/user memory disclosure.\nI:H - The same bogus folio can be isolated from the LRU and handed to migrate_pages(), silently moving an unrelated live folio and enabling use-after-free, page-table corruption, and control-flow hijack.\nA:H - A bogus vmemmap dereference oopses the kernel, debug builds hit VM_BUG_ON, and isolating or migrating the wrong folio can panic or hang the system."
            }
          ]
        }
      ],
      "providerMetadata": {
        "dateUpdated": "2026-10-19T08:52:11.845Z",
        "orgId": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
        "shortName": "Linux"
      },
      "references": [
        {
          "url": "https://git.kernel.org/stable/c/3d927093b2add7ced588a926c3dc5d7a83f18596"
        },
        {
          "url": "https://git.kernel.org/stable/c/2858b4027f491e6fdb8ee2d8923798b619bf2791"
        }
      ],
      "title": "mm/mempolicy: skip non-present PMDs when queueing folios",
      "x_generator": {
        "engine": "bippy-1.2.0"
      }
    }
  },
  "cveMetadata": {
    "assignerOrgId": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
    "assignerShortName": "Linux",
    "cveId": "CVE-2026-89758",
    "datePublished": "2026-09-11T19:47:00.562Z",
    "dateReserved": "2026-09-11T19:38:34.763Z",
    "dateUpdated": "2026-10-19T08:52:11.845Z",
    "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