CVE-2025-37868 (GCVE-0-2025-37868)
Vulnerability from cvelistv5
Published
2025-05-09 06:43
Modified
2025-05-26 05:22
Severity ?
Summary
In the Linux kernel, the following vulnerability has been resolved: drm/xe/userptr: fix notifier vs folio deadlock User is reporting what smells like notifier vs folio deadlock, where migrate_pages_batch() on core kernel side is holding folio lock(s) and then interacting with the mappings of it, however those mappings are tied to some userptr, which means calling into the notifier callback and grabbing the notifier lock. With perfect timing it looks possible that the pages we pulled from the hmm fault can get sniped by migrate_pages_batch() at the same time that we are holding the notifier lock to mark the pages as accessed/dirty, but at this point we also want to grab the folio locks(s) to mark them as dirty, but if they are contended from notifier/migrate_pages_batch side then we deadlock since folio lock won't be dropped until we drop the notifier lock. Fortunately the mark_page_accessed/dirty is not really needed in the first place it seems and should have already been done by hmm fault, so just remove it. (cherry picked from commit bd7c0cb695e87c0e43247be8196b4919edbe0e85)
Impacted products
Vendor Product Version
Linux Linux Version: 2a24c98f0e4cc994334598d4f3a851972064809d
Version: 0a98219bcc961edd3388960576e4353e123b4a51
Version: 0a98219bcc961edd3388960576e4353e123b4a51
Version: f9326f529da7298a95643c3267f1c0fdb0db55eb
Create a notification for this product.
Show details on NVD website


{
  "containers": {
    "cna": {
      "affected": [
        {
          "defaultStatus": "unaffected",
          "product": "Linux",
          "programFiles": [
            "drivers/gpu/drm/xe/xe_hmm.c"
          ],
          "repo": "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git",
          "vendor": "Linux",
          "versions": [
            {
              "lessThan": "65dc4e3d5b01db0179fc95c1f0bdb87194c28ab5",
              "status": "affected",
              "version": "2a24c98f0e4cc994334598d4f3a851972064809d",
              "versionType": "git"
            },
            {
              "lessThan": "90574ecf6052be83971d91d16600c5cf07003bbb",
              "status": "affected",
              "version": "0a98219bcc961edd3388960576e4353e123b4a51",
              "versionType": "git"
            },
            {
              "lessThan": "2577b202458cddff85cc154b1fe7f313e0d1f418",
              "status": "affected",
              "version": "0a98219bcc961edd3388960576e4353e123b4a51",
              "versionType": "git"
            },
            {
              "status": "affected",
              "version": "f9326f529da7298a95643c3267f1c0fdb0db55eb",
              "versionType": "git"
            }
          ]
        },
        {
          "defaultStatus": "affected",
          "product": "Linux",
          "programFiles": [
            "drivers/gpu/drm/xe/xe_hmm.c"
          ],
          "repo": "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git",
          "vendor": "Linux",
          "versions": [
            {
              "status": "affected",
              "version": "6.14"
            },
            {
              "lessThan": "6.14",
              "status": "unaffected",
              "version": "0",
              "versionType": "semver"
            },
            {
              "lessThanOrEqual": "6.12.*",
              "status": "unaffected",
              "version": "6.12.25",
              "versionType": "semver"
            },
            {
              "lessThanOrEqual": "6.14.*",
              "status": "unaffected",
              "version": "6.14.4",
              "versionType": "semver"
            },
            {
              "lessThanOrEqual": "*",
              "status": "unaffected",
              "version": "6.15",
              "versionType": "original_commit_for_fix"
            }
          ]
        }
      ],
      "cpeApplicability": [
        {
          "nodes": [
            {
              "cpeMatch": [
                {
                  "criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
                  "versionEndExcluding": "6.12.25",
                  "versionStartIncluding": "6.12.19",
                  "vulnerable": true
                },
                {
                  "criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
                  "versionEndExcluding": "6.14.4",
                  "versionStartIncluding": "6.14",
                  "vulnerable": true
                },
                {
                  "criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
                  "versionEndExcluding": "6.15",
                  "versionStartIncluding": "6.14",
                  "vulnerable": true
                },
                {
                  "criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
                  "versionStartIncluding": "6.13.7",
                  "vulnerable": true
                }
              ],
              "negate": false,
              "operator": "OR"
            }
          ]
        }
      ],
      "descriptions": [
        {
          "lang": "en",
          "value": "In the Linux kernel, the following vulnerability has been resolved:\n\ndrm/xe/userptr: fix notifier vs folio deadlock\n\nUser is reporting what smells like notifier vs folio deadlock, where\nmigrate_pages_batch() on core kernel side is holding folio lock(s) and\nthen interacting with the mappings of it, however those mappings are\ntied to some userptr, which means calling into the notifier callback and\ngrabbing the notifier lock. With perfect timing it looks possible that\nthe pages we pulled from the hmm fault can get sniped by\nmigrate_pages_batch() at the same time that we are holding the notifier\nlock to mark the pages as accessed/dirty, but at this point we also want\nto grab the folio locks(s) to mark them as dirty, but if they are\ncontended from notifier/migrate_pages_batch side then we deadlock since\nfolio lock won\u0027t be dropped until we drop the notifier lock.\n\nFortunately the mark_page_accessed/dirty is not really needed in the\nfirst place it seems and should have already been done by hmm fault, so\njust remove it.\n\n(cherry picked from commit bd7c0cb695e87c0e43247be8196b4919edbe0e85)"
        }
      ],
      "providerMetadata": {
        "dateUpdated": "2025-05-26T05:22:39.786Z",
        "orgId": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
        "shortName": "Linux"
      },
      "references": [
        {
          "url": "https://git.kernel.org/stable/c/65dc4e3d5b01db0179fc95c1f0bdb87194c28ab5"
        },
        {
          "url": "https://git.kernel.org/stable/c/90574ecf6052be83971d91d16600c5cf07003bbb"
        },
        {
          "url": "https://git.kernel.org/stable/c/2577b202458cddff85cc154b1fe7f313e0d1f418"
        }
      ],
      "title": "drm/xe/userptr: fix notifier vs folio deadlock",
      "x_generator": {
        "engine": "bippy-1.2.0"
      }
    }
  },
  "cveMetadata": {
    "assignerOrgId": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
    "assignerShortName": "Linux",
    "cveId": "CVE-2025-37868",
    "datePublished": "2025-05-09T06:43:57.383Z",
    "dateReserved": "2025-04-16T04:51:23.959Z",
    "dateUpdated": "2025-05-26T05:22:39.786Z",
    "state": "PUBLISHED"
  },
  "dataType": "CVE_RECORD",
  "dataVersion": "5.1",
  "vulnerability-lookup:meta": {
    "nvd": "{\"cve\":{\"id\":\"CVE-2025-37868\",\"sourceIdentifier\":\"416baaa9-dc9f-4396-8d5f-8c081fb06d67\",\"published\":\"2025-05-09T07:16:07.880\",\"lastModified\":\"2025-05-12T17:32:32.760\",\"vulnStatus\":\"Awaiting Analysis\",\"cveTags\":[],\"descriptions\":[{\"lang\":\"en\",\"value\":\"In the Linux kernel, the following vulnerability has been resolved:\\n\\ndrm/xe/userptr: fix notifier vs folio deadlock\\n\\nUser is reporting what smells like notifier vs folio deadlock, where\\nmigrate_pages_batch() on core kernel side is holding folio lock(s) and\\nthen interacting with the mappings of it, however those mappings are\\ntied to some userptr, which means calling into the notifier callback and\\ngrabbing the notifier lock. With perfect timing it looks possible that\\nthe pages we pulled from the hmm fault can get sniped by\\nmigrate_pages_batch() at the same time that we are holding the notifier\\nlock to mark the pages as accessed/dirty, but at this point we also want\\nto grab the folio locks(s) to mark them as dirty, but if they are\\ncontended from notifier/migrate_pages_batch side then we deadlock since\\nfolio lock won\u0027t be dropped until we drop the notifier lock.\\n\\nFortunately the mark_page_accessed/dirty is not really needed in the\\nfirst place it seems and should have already been done by hmm fault, so\\njust remove it.\\n\\n(cherry picked from commit bd7c0cb695e87c0e43247be8196b4919edbe0e85)\"},{\"lang\":\"es\",\"value\":\"En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: drm/xe/userptr: fix notifier vs folio deadlock El usuario informa lo que parece ser un deadlock entre notifier y folio, donde migration_pages_batch() en el lado del n\u00facleo central mantiene el bloqueo de folio y luego interact\u00faa con las asignaciones de este, sin embargo, esas asignaciones est\u00e1n vinculadas a alg\u00fan userptr, lo que significa llamar a la devoluci\u00f3n de llamada del notificador y tomar el bloqueo del notificador. Con una sincronizaci\u00f3n perfecta, parece posible que las p\u00e1ginas que extrajimos de la falla hmm puedan ser atacadas por migration_pages_batch() al mismo tiempo que mantenemos el bloqueo del notificador para marcar las p\u00e1ginas como accedidas/sucias, pero en este punto tambi\u00e9n queremos tomar el bloqueo de folio para marcarlos como sucios, pero si se disputan desde el lado de notifier/migrate_pages_batch, entonces nos bloqueamos ya que el bloqueo de folio no se eliminar\u00e1 hasta que eliminemos el bloqueo del notificador. Afortunadamente, mark_page_accessed/dirty no es realmente necesario en primer lugar, al parecer, y ya deber\u00eda haber sido realizado por hmm fault, as\u00ed que simplemente elim\u00ednelo. (seleccionado del commit bd7c0cb695e87c0e43247be8196b4919edbe0e85)\"}],\"metrics\":{},\"references\":[{\"url\":\"https://git.kernel.org/stable/c/2577b202458cddff85cc154b1fe7f313e0d1f418\",\"source\":\"416baaa9-dc9f-4396-8d5f-8c081fb06d67\"},{\"url\":\"https://git.kernel.org/stable/c/65dc4e3d5b01db0179fc95c1f0bdb87194c28ab5\",\"source\":\"416baaa9-dc9f-4396-8d5f-8c081fb06d67\"},{\"url\":\"https://git.kernel.org/stable/c/90574ecf6052be83971d91d16600c5cf07003bbb\",\"source\":\"416baaa9-dc9f-4396-8d5f-8c081fb06d67\"}]}}"
  }
}


Log in or create an account to share your comment.




Tags
Taxonomy of the tags.


Loading…

Loading…

Loading…

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.


Loading…

Loading…