CVE-2025-37760 (GCVE-0-2025-37760)
Vulnerability from cvelistv5
Published
2025-05-01 13:07
Modified
2025-05-26 05:20
Severity ?
Summary
In the Linux kernel, the following vulnerability has been resolved: mm/vma: add give_up_on_oom option on modify/merge, use in uffd release Currently, if a VMA merge fails due to an OOM condition arising on commit merge or a failure to duplicate anon_vma's, we report this so the caller can handle it. However there are cases where the caller is only ostensibly trying a merge, and doesn't mind if it fails due to this condition. Since we do not want to introduce an implicit assumption that we only actually modify VMAs after OOM conditions might arise, add a 'give up on oom' option and make an explicit contract that, should this flag be set, we absolutely will not modify any VMAs should OOM arise and just bail out. Since it'd be very unusual for a user to try to vma_modify() with this flag set but be specifying a range within a VMA which ends up being split (which can fail due to rlimit issues, not only OOM), we add a debug warning for this condition. The motivating reason for this is uffd release - syzkaller (and Pedro Falcato's VERY astute analysis) found a way in which an injected fault on allocation, triggering an OOM condition on commit merge, would result in uffd code becoming confused and treating an error value as if it were a VMA pointer. To avoid this, we make use of this new VMG flag to ensure that this never occurs, utilising the fact that, should we be clearing entire VMAs, we do not wish an OOM event to be reported to us. Many thanks to Pedro Falcato for his excellent analysis and Jann Horn for his insightful and intelligent analysis of the situation, both of whom were instrumental in this fix.
Impacted products
Vendor Product Version
Linux Linux Version: 79636d2981b066acd945117387a9533f56411f6f
Version: 47b16d0462a460000b8f05dfb1292377ac48f3ca
Version: 47b16d0462a460000b8f05dfb1292377ac48f3ca
Version: 53fd215f7886a1e8dea5a9ca1391dbb697fff601
Create a notification for this product.
Show details on NVD website


{
  "containers": {
    "cna": {
      "affected": [
        {
          "defaultStatus": "unaffected",
          "product": "Linux",
          "programFiles": [
            "mm/userfaultfd.c",
            "mm/vma.c",
            "mm/vma.h"
          ],
          "repo": "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git",
          "vendor": "Linux",
          "versions": [
            {
              "lessThan": "b906c1ad25adce6ff35be19b65a1aa7d960fe1d7",
              "status": "affected",
              "version": "79636d2981b066acd945117387a9533f56411f6f",
              "versionType": "git"
            },
            {
              "lessThan": "c103a75c61648203d731e3b97a6fbeea4003cb15",
              "status": "affected",
              "version": "47b16d0462a460000b8f05dfb1292377ac48f3ca",
              "versionType": "git"
            },
            {
              "lessThan": "41e6ddcaa0f18dda4c3fadf22533775a30d6f72f",
              "status": "affected",
              "version": "47b16d0462a460000b8f05dfb1292377ac48f3ca",
              "versionType": "git"
            },
            {
              "status": "affected",
              "version": "53fd215f7886a1e8dea5a9ca1391dbb697fff601",
              "versionType": "git"
            }
          ]
        },
        {
          "defaultStatus": "affected",
          "product": "Linux",
          "programFiles": [
            "mm/userfaultfd.c",
            "mm/vma.c",
            "mm/vma.h"
          ],
          "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\nmm/vma: add give_up_on_oom option on modify/merge, use in uffd release\n\nCurrently, if a VMA merge fails due to an OOM condition arising on commit\nmerge or a failure to duplicate anon_vma\u0027s, we report this so the caller\ncan handle it.\n\nHowever there are cases where the caller is only ostensibly trying a\nmerge, and doesn\u0027t mind if it fails due to this condition.\n\nSince we do not want to introduce an implicit assumption that we only\nactually modify VMAs after OOM conditions might arise, add a \u0027give up on\noom\u0027 option and make an explicit contract that, should this flag be set, we\nabsolutely will not modify any VMAs should OOM arise and just bail out.\n\nSince it\u0027d be very unusual for a user to try to vma_modify() with this flag\nset but be specifying a range within a VMA which ends up being split (which\ncan fail due to rlimit issues, not only OOM), we add a debug warning for\nthis condition.\n\nThe motivating reason for this is uffd release - syzkaller (and Pedro\nFalcato\u0027s VERY astute analysis) found a way in which an injected fault on\nallocation, triggering an OOM condition on commit merge, would result in\nuffd code becoming confused and treating an error value as if it were a VMA\npointer.\n\nTo avoid this, we make use of this new VMG flag to ensure that this never\noccurs, utilising the fact that, should we be clearing entire VMAs, we do\nnot wish an OOM event to be reported to us.\n\nMany thanks to Pedro Falcato for his excellent analysis and Jann Horn for\nhis insightful and intelligent analysis of the situation, both of whom were\ninstrumental in this fix."
        }
      ],
      "providerMetadata": {
        "dateUpdated": "2025-05-26T05:20:17.391Z",
        "orgId": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
        "shortName": "Linux"
      },
      "references": [
        {
          "url": "https://git.kernel.org/stable/c/b906c1ad25adce6ff35be19b65a1aa7d960fe1d7"
        },
        {
          "url": "https://git.kernel.org/stable/c/c103a75c61648203d731e3b97a6fbeea4003cb15"
        },
        {
          "url": "https://git.kernel.org/stable/c/41e6ddcaa0f18dda4c3fadf22533775a30d6f72f"
        }
      ],
      "title": "mm/vma: add give_up_on_oom option on modify/merge, use in uffd release",
      "x_generator": {
        "engine": "bippy-1.2.0"
      }
    }
  },
  "cveMetadata": {
    "assignerOrgId": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
    "assignerShortName": "Linux",
    "cveId": "CVE-2025-37760",
    "datePublished": "2025-05-01T13:07:02.617Z",
    "dateReserved": "2025-04-16T04:51:23.938Z",
    "dateUpdated": "2025-05-26T05:20:17.391Z",
    "state": "PUBLISHED"
  },
  "dataType": "CVE_RECORD",
  "dataVersion": "5.1",
  "vulnerability-lookup:meta": {
    "nvd": "{\"cve\":{\"id\":\"CVE-2025-37760\",\"sourceIdentifier\":\"416baaa9-dc9f-4396-8d5f-8c081fb06d67\",\"published\":\"2025-05-01T14:15:38.110\",\"lastModified\":\"2025-05-02T13:53:20.943\",\"vulnStatus\":\"Awaiting Analysis\",\"cveTags\":[],\"descriptions\":[{\"lang\":\"en\",\"value\":\"In the Linux kernel, the following vulnerability has been resolved:\\n\\nmm/vma: add give_up_on_oom option on modify/merge, use in uffd release\\n\\nCurrently, if a VMA merge fails due to an OOM condition arising on commit\\nmerge or a failure to duplicate anon_vma\u0027s, we report this so the caller\\ncan handle it.\\n\\nHowever there are cases where the caller is only ostensibly trying a\\nmerge, and doesn\u0027t mind if it fails due to this condition.\\n\\nSince we do not want to introduce an implicit assumption that we only\\nactually modify VMAs after OOM conditions might arise, add a \u0027give up on\\noom\u0027 option and make an explicit contract that, should this flag be set, we\\nabsolutely will not modify any VMAs should OOM arise and just bail out.\\n\\nSince it\u0027d be very unusual for a user to try to vma_modify() with this flag\\nset but be specifying a range within a VMA which ends up being split (which\\ncan fail due to rlimit issues, not only OOM), we add a debug warning for\\nthis condition.\\n\\nThe motivating reason for this is uffd release - syzkaller (and Pedro\\nFalcato\u0027s VERY astute analysis) found a way in which an injected fault on\\nallocation, triggering an OOM condition on commit merge, would result in\\nuffd code becoming confused and treating an error value as if it were a VMA\\npointer.\\n\\nTo avoid this, we make use of this new VMG flag to ensure that this never\\noccurs, utilising the fact that, should we be clearing entire VMAs, we do\\nnot wish an OOM event to be reported to us.\\n\\nMany thanks to Pedro Falcato for his excellent analysis and Jann Horn for\\nhis insightful and intelligent analysis of the situation, both of whom were\\ninstrumental in this fix.\"},{\"lang\":\"es\",\"value\":\"En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: mm/vma: a\u00f1adir la opci\u00f3n give_up_on_oom en modificar/fusionar, usar en la versi\u00f3n uffd Actualmente, si una fusi\u00f3n de VMA falla debido a una condici\u00f3n OOM que surge en la fusi\u00f3n de confirmaci\u00f3n o un fallo al duplicar anon_vma, informamos de ello para que el llamador pueda gestionarlo. Sin embargo, hay casos en los que el llamador solo est\u00e1 intentando una fusi\u00f3n ostensiblemente y no le importa si falla debido a esta condici\u00f3n. Dado que no queremos introducir una suposici\u00f3n impl\u00edcita de que solo modificamos realmente los VMA despu\u00e9s de que puedan surgir condiciones OOM, agregue una opci\u00f3n \u0027renunciar a oom\u0027 y haga un contrato expl\u00edcito de que, si se establece este indicador, no modificaremos en absoluto ning\u00fan VMA si surge OOM y simplemente nos retiraremos. Dado que ser\u00eda muy inusual que un usuario intentara usar vma_modify() con este indicador activado, pero especificando un rango dentro de un VMA que termina dividi\u00e9ndose (lo cual puede fallar debido a problemas con rlimit, no solo por OOM), a\u00f1adimos una advertencia de depuraci\u00f3n para esta condici\u00f3n. El motivo es la versi\u00f3n de uffd: syzkaller (y el astuto an\u00e1lisis de Pedro Falcato) encontr\u00f3 una forma en la que un fallo inyectado en la asignaci\u00f3n, que desencadena una condici\u00f3n OOM al fusionar las confirmaciones, provocaba que el c\u00f3digo de uffd se confundiera y tratara un valor de error como si fuera un puntero a un VMA. Para evitar esto, utilizamos este nuevo indicador VMG para asegurarnos de que esto nunca ocurra, aprovechando que, si borramos VMAs completas, no queremos que se nos informe de un evento OOM. Muchas gracias a Pedro Falcato por su excelente an\u00e1lisis y a Jann Horn por su perspicaz e inteligente an\u00e1lisis de la situaci\u00f3n, ambos fundamentales en esta soluci\u00f3n.\"}],\"metrics\":{},\"references\":[{\"url\":\"https://git.kernel.org/stable/c/41e6ddcaa0f18dda4c3fadf22533775a30d6f72f\",\"source\":\"416baaa9-dc9f-4396-8d5f-8c081fb06d67\"},{\"url\":\"https://git.kernel.org/stable/c/b906c1ad25adce6ff35be19b65a1aa7d960fe1d7\",\"source\":\"416baaa9-dc9f-4396-8d5f-8c081fb06d67\"},{\"url\":\"https://git.kernel.org/stable/c/c103a75c61648203d731e3b97a6fbeea4003cb15\",\"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…