fkie_cve-2025-38084
Vulnerability from fkie_nvd
Published
2025-06-28 08:15
Modified
2025-07-30 06:15
Severity ?
Summary
In the Linux kernel, the following vulnerability has been resolved: mm/hugetlb: unshare page tables during VMA split, not before Currently, __split_vma() triggers hugetlb page table unsharing through vm_ops->may_split(). This happens before the VMA lock and rmap locks are taken - which is too early, it allows racing VMA-locked page faults in our process and racing rmap walks from other processes to cause page tables to be shared again before we actually perform the split. Fix it by explicitly calling into the hugetlb unshare logic from __split_vma() in the same place where THP splitting also happens. At that point, both the VMA and the rmap(s) are write-locked. An annoying detail is that we can now call into the helper hugetlb_unshare_pmds() from two different locking contexts: 1. from hugetlb_split(), holding: - mmap lock (exclusively) - VMA lock - file rmap lock (exclusively) 2. hugetlb_unshare_all_pmds(), which I think is designed to be able to call us with only the mmap lock held (in shared mode), but currently only runs while holding mmap lock (exclusively) and VMA lock Backporting note: This commit fixes a racy protection that was introduced in commit b30c14cd6102 ("hugetlb: unshare some PMDs when splitting VMAs"); that commit claimed to fix an issue introduced in 5.13, but it should actually also go all the way back. [jannh@google.com: v2]
References
416baaa9-dc9f-4396-8d5f-8c081fb06d67https://git.kernel.org/stable/c/081056dc00a27bccb55ccc3c6f230a3d5fd3f7e0
416baaa9-dc9f-4396-8d5f-8c081fb06d67https://git.kernel.org/stable/c/2511ac64bc1617ca716d3ba8464e481a647c1902
416baaa9-dc9f-4396-8d5f-8c081fb06d67https://git.kernel.org/stable/c/366298f2b04d2bf1f2f2b7078405bdf9df9bd5d0
416baaa9-dc9f-4396-8d5f-8c081fb06d67https://git.kernel.org/stable/c/8a21d5584826f4880f45bbf8f72375f4e6c0ff2a
416baaa9-dc9f-4396-8d5f-8c081fb06d67https://git.kernel.org/stable/c/9cf5b2a3b72c23fb7b84736d5d19ee6ea718762b
416baaa9-dc9f-4396-8d5f-8c081fb06d67https://git.kernel.org/stable/c/af6cfcd0efb7f051af221c418ec8b37a10211947
416baaa9-dc9f-4396-8d5f-8c081fb06d67https://git.kernel.org/stable/c/e8847d18cd9fff1edbb45e963d9141273c3b539c
416baaa9-dc9f-4396-8d5f-8c081fb06d67https://project-zero.issues.chromium.org/issues/420715744
Impacted products
Vendor Product Version


To clipboard 

{
  "cveTags": [],
  "descriptions": [
    {
      "lang": "en",
      "value": "In the Linux kernel, the following vulnerability has been resolved:\n\nmm/hugetlb: unshare page tables during VMA split, not before\n\nCurrently, __split_vma() triggers hugetlb page table unsharing through\nvm_ops-\u003emay_split().  This happens before the VMA lock and rmap locks are\ntaken - which is too early, it allows racing VMA-locked page faults in our\nprocess and racing rmap walks from other processes to cause page tables to\nbe shared again before we actually perform the split.\n\nFix it by explicitly calling into the hugetlb unshare logic from\n__split_vma() in the same place where THP splitting also happens.  At that\npoint, both the VMA and the rmap(s) are write-locked.\n\nAn annoying detail is that we can now call into the helper\nhugetlb_unshare_pmds() from two different locking contexts:\n\n1. from hugetlb_split(), holding:\n    - mmap lock (exclusively)\n    - VMA lock\n    - file rmap lock (exclusively)\n2. hugetlb_unshare_all_pmds(), which I think is designed to be able to\n   call us with only the mmap lock held (in shared mode), but currently\n   only runs while holding mmap lock (exclusively) and VMA lock\n\nBackporting note:\nThis commit fixes a racy protection that was introduced in commit\nb30c14cd6102 (\"hugetlb: unshare some PMDs when splitting VMAs\"); that\ncommit claimed to fix an issue introduced in 5.13, but it should actually\nalso go all the way back.\n\n[jannh@google.com: v2]"
    },
    {
      "lang": "es",
      "value": "En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: mm/hugetlb: dejar de compartir tablas de p\u00e1ginas durante la divisi\u00f3n de VMA, no antes. Actualmente, __split_vma() activa la descompartici\u00f3n de la tabla de p\u00e1ginas hugetlb a trav\u00e9s de vm_ops-\u0026gt;may_split(). Esto sucede antes de que se tomen los bloqueos de VMA y rmap, lo cual es demasiado pronto, ya que permite que las fallas de p\u00e1gina bloqueadas por VMA en nuestro proceso y los recorridos rmap de otros procesos provoquen que las tablas de p\u00e1ginas se compartan de nuevo antes de que realmente realicemos la divisi\u00f3n. Corr\u00edjalo llamando expl\u00edcitamente a la l\u00f3gica de descompartir hugetlb desde __split_vma() en el mismo lugar donde tambi\u00e9n ocurre la divisi\u00f3n de THP. En ese punto, tanto el VMA como los rmap est\u00e1n bloqueados contra escritura. Un detalle molesto es que ahora podemos llamar al asistente hugetlb_unshare_pmds() desde dos contextos de bloqueo diferentes: 1. desde hugetlb_split(), que contiene: - bloqueo mmap (exclusivamente) - bloqueo VMA - bloqueo rmap de archivo (exclusivamente) 2. hugetlb_unshare_all_pmds(), que creo que est\u00e1 dise\u00f1ado para poder llamarnos con solo el bloqueo mmap mantenido (en modo compartido), pero actualmente solo se ejecuta mientras se mantiene el bloqueo mmap (exclusivamente) y el bloqueo VMA. Nota de retroportaci\u00f3n: Este commit corrige una protecci\u00f3n contra la exposici\u00f3n a riesgos que se introdujo en el commit b30c14cd6102 (\"hugetlb: dejar de compartir algunos PMD al dividir VMA\"); es commit afirmaba corregir un problema introducido en la versi\u00f3n 5.13, pero en realidad tambi\u00e9n deber\u00eda retroceder. [jannh@google.com: v2]"
    }
  ],
  "id": "CVE-2025-38084",
  "lastModified": "2025-07-30T06:15:26.867",
  "metrics": {},
  "published": "2025-06-28T08:15:23.970",
  "references": [
    {
      "source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
      "url": "https://git.kernel.org/stable/c/081056dc00a27bccb55ccc3c6f230a3d5fd3f7e0"
    },
    {
      "source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
      "url": "https://git.kernel.org/stable/c/2511ac64bc1617ca716d3ba8464e481a647c1902"
    },
    {
      "source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
      "url": "https://git.kernel.org/stable/c/366298f2b04d2bf1f2f2b7078405bdf9df9bd5d0"
    },
    {
      "source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
      "url": "https://git.kernel.org/stable/c/8a21d5584826f4880f45bbf8f72375f4e6c0ff2a"
    },
    {
      "source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
      "url": "https://git.kernel.org/stable/c/9cf5b2a3b72c23fb7b84736d5d19ee6ea718762b"
    },
    {
      "source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
      "url": "https://git.kernel.org/stable/c/af6cfcd0efb7f051af221c418ec8b37a10211947"
    },
    {
      "source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
      "url": "https://git.kernel.org/stable/c/e8847d18cd9fff1edbb45e963d9141273c3b539c"
    },
    {
      "source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
      "url": "https://project-zero.issues.chromium.org/issues/420715744"
    }
  ],
  "sourceIdentifier": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
  "vulnStatus": "Awaiting Analysis"
}


Log in or create an account to share your comment.




Tags
Taxonomy of the tags.




Sightings

Author Source Type Date

Nomenclature

  • Seen: The vulnerability was mentioned, discussed, or seen somewhere by the user.
  • Confirmed: The vulnerability is confirmed from an analyst perspective.
  • Exploited: This vulnerability was exploited and seen by the user reporting the sighting.
  • Patched: This vulnerability was successfully patched by the user reporting the sighting.
  • Not exploited: This vulnerability was not exploited or seen by the user reporting the sighting.
  • Not confirmed: The user expresses doubt about the veracity of the vulnerability.
  • Not patched: This vulnerability was not successfully patched by the user reporting the sighting.