GHSA-MC2F-CM9P-679Q

Vulnerability from github – Published: 2026-08-10 15:33 – Updated: 2026-08-14 00:31
VLAI
Details

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

arm64: make huge_ptep_get handled unaligned addresses

huge_ptep_get() can be handed a virtual address pointing to the middle of a contpmd/contpte mapped hugetlb folio (examples of callers are pagemap_hugetlb_range, page_mapped_in_vma).

The arm64 helper rewalks the pgtables in find_num_contig to answer whether the huge pte we have maps a contpmd or a contpte hugetlb folio, and returns CONT_PMDS or CONT_PTES, so that it can collect a/d bits over the contiguous ptes. We can falsely return CONT_PTES instead of CONT_PMDS if the addr is not aligned. On systems where CONT_PTES != CONT_PMDS (meaning page size is 16K), we could collect excess A/D bit state, meaning extra work for the kernel. Even worse, we may iterate beyond the PTE table and dereference a garbage ptep pointer to access physical memory we don't own. Since the ptep pointer is a linear map address, we may run off the end of the linear map or into a hole, dereference a VA not mapped into the kernel pgtables and cause kernel panic.

Fix this by aligning the pmdp pointer down to a contpmd base before checking equality with the passed huge pte pointer, to correctly answer whether the huge pte is the base of a contpmd block.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2026-68172"
  ],
  "database_specific": {
    "cwe_ids": [],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2026-08-10T13:20:03Z",
    "severity": "HIGH"
  },
  "details": "In the Linux kernel, the following vulnerability has been resolved:\n\narm64: make huge_ptep_get handled unaligned addresses\n\nhuge_ptep_get() can be handed a virtual address pointing to the middle\nof a contpmd/contpte mapped hugetlb folio (examples of callers are\npagemap_hugetlb_range, page_mapped_in_vma).\n\nThe arm64 helper rewalks the pgtables in find_num_contig to answer\nwhether the huge pte we have maps a contpmd or a contpte hugetlb folio,\nand returns CONT_PMDS or CONT_PTES, so that it can collect a/d bits over\nthe contiguous ptes. We can falsely return CONT_PTES instead of\nCONT_PMDS if the addr is not aligned. On systems where CONT_PTES !=\nCONT_PMDS (meaning page size is 16K), we could collect excess A/D bit\nstate, meaning extra work for the kernel. Even worse, we may iterate\nbeyond the PTE table and dereference a garbage ptep pointer to access\nphysical memory we don\u0027t own. Since the ptep pointer is a linear map\naddress, we may run off the end of the linear map or into a hole,\ndereference a VA not mapped into the kernel pgtables and cause kernel\npanic.\n\nFix this by aligning the pmdp pointer down to a contpmd base before\nchecking equality with the passed huge pte pointer, to correctly answer\nwhether the huge pte is the base of a contpmd block.",
  "id": "GHSA-mc2f-cm9p-679q",
  "modified": "2026-08-14T00:31:52Z",
  "published": "2026-08-10T15:33:39Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-68172"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/9cd4b1a52eff330798d668c1775f8bc450776280"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/f3530aec26563f4d483ff31402392961362e9bc6"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/f73a8edc2ccc6ec72c37d5c578e7592d2e1f9922"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:N/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…

Loading…