GHSA-JX9M-72FR-5V84

Vulnerability from github – Published: 2026-07-19 18:31 – Updated: 2026-07-20 15:32
VLAI
Details

In the Linux kernel, the following vulnerability has been resolved:

mm: fix __vm_normal_page() to handle missing support for pmd_special()/pud_special()

On x86 32-bit with THP enabled, zap_huge_pmd() is seen to generate a "WARNING: mm/memory.c:735 at __vm_normal_page+0x6a/0x7d", from the VM_WARN_ON_ONCE(is_zero_pfn(pfn) || is_huge_zero_pfn(pfn)); followed by "BUG: Bad rss-counter state"s, then later "BUG: Bad page state"s when reclaim gets to call shrink_huge_zero_folio_scan().

It's as if the _PAGE_SPECIAL bit never got set in the huge_zero pmd: and indeed, whereas pte_special() and pte_mkspecial() are subject to a dedicated CONFIG_ARCH_HAS_PTE_SPECIAL, pmd_special() and pmd_mkspecial() are subject to CONFIG_ARCH_SUPPORTS_PMD_PFNMAP, which is never enabled on any 32-bit architecture.

While the problem was exposed through commit d80a9cb1a64a ("mm/huge_memory: add and use normal_or_softleaf_folio_pmd()"), it was an oversight in commit af38538801c6 ("mm/memory: factor out common code from vm_normal_page_*()") and would result in other problems: * huge zero folio accounted in smaps, pagemap (PAGE_IS_FILE) and numamaps as file-backed THP * folio_walk_start() returning the folio even without FW_ZEROPAGE set. Callers seem to tolerate that, though.

... and triggering the VM_WARN_ON_ONE(), although never reported so far.

To fix it, teach vm_normal_page_pmd()/vm_normal_page_pud() to consider whether pmd_special/pud_special is actually implemented.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2026-64181"
  ],
  "database_specific": {
    "cwe_ids": [],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2026-07-19T16:18:00Z",
    "severity": "HIGH"
  },
  "details": "In the Linux kernel, the following vulnerability has been resolved:\n\nmm: fix __vm_normal_page() to handle missing support for pmd_special()/pud_special()\n\nOn x86 32-bit with THP enabled, zap_huge_pmd() is seen to generate a\n\"WARNING: mm/memory.c:735 at __vm_normal_page+0x6a/0x7d\", from the\nVM_WARN_ON_ONCE(is_zero_pfn(pfn) || is_huge_zero_pfn(pfn)); followed by\n\"BUG: Bad rss-counter state\"s, then later \"BUG: Bad page state\"s when\nreclaim gets to call shrink_huge_zero_folio_scan().\n\nIt\u0027s as if the _PAGE_SPECIAL bit never got set in the huge_zero pmd: and\nindeed, whereas pte_special() and pte_mkspecial() are subject to a\ndedicated CONFIG_ARCH_HAS_PTE_SPECIAL, pmd_special() and pmd_mkspecial()\nare subject to CONFIG_ARCH_SUPPORTS_PMD_PFNMAP, which is never enabled on\nany 32-bit architecture.\n\nWhile the problem was exposed through commit d80a9cb1a64a\n(\"mm/huge_memory: add and use normal_or_softleaf_folio_pmd()\"), it was an\noversight in commit af38538801c6 (\"mm/memory: factor out common code from\nvm_normal_page_*()\") and would result in other problems:\n* huge zero folio accounted in smaps, pagemap (PAGE_IS_FILE) and\n  numamaps as file-backed THP\n* folio_walk_start() returning the folio even without FW_ZEROPAGE set.\n  Callers seem to tolerate that, though.\n\n... and triggering the VM_WARN_ON_ONE(), although never reported so far.\n\nTo fix it, teach vm_normal_page_pmd()/vm_normal_page_pud() to consider\nwhether pmd_special/pud_special is actually implemented.",
  "id": "GHSA-jx9m-72fr-5v84",
  "modified": "2026-07-20T15:32:02Z",
  "published": "2026-07-19T18:31:54Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-64181"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/62153767e8fc3889bc6508e9ffe927aaf64c4334"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/9052ea2ee2233be5d4786b8909151ca2bfbedf99"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/c0c6ccd9828c3a1950623b546fa57292a77b5c73"
    }
  ],
  "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"
    }
  ]
}



Log in or create an account to share your comment.




Tags
Taxonomy of the tags.


Loading…

Loading…

Loading…

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.

Loading…

Detection rules are retrieved from Rulezet.

Loading…

Loading…