Skip to content
Heist/ feed
Back to feed
HighFix available

mm: abort vma_modify() on merge out of memory failure

Type: advisorySources: OSV

In the Linux kernel, the following vulnerability has been resolved: mm: abort vma_modify() on merge out of memory failure The remainder of vma_modify() relies upon the vmg state remaining pristine after a merge attempt. Usually this is the case, however in the one edge case scenario of a merge attempt failing not due to the specified range being unmergeable, but rather due to an out of memory error arising when attempting to commit the merge, this assumption becomes untrue. This results in vmg->start, end being modified, and thus the proceeding attempts to split the VMA will be done with invalid start/end values. Thankfully, it is likely practically impossible for us to hit this in reality, as it would require a maple tree node pre-allocation failure that would likely never happen due to it being 'too small to fail', i.e. the kernel would simply keep retrying reclaim until it succeeded. However, this scenario remains theoretically possible, and what we are doing here is wrong so we must correct it. The safest option is, when this scenario occurs, to simply give up the operation. If we cannot allocate memory to merge, then we cannot allocate memory to split either (perhaps moreso!). Any scenario where this would be happening would be under very extreme (likely fatal) memory pressure, so it's best we give up early. So there is no doubt it is appropriate to simply bail out in this scenario. However, in general we must if at all possible never assume VMG state is stable after a m

Products
Kernel
Affected versions
Not specified
Fixed versions
6.12.19, 6.13.7
CVEs
CVE-2025-21932
Confirmed fixed CVEs
Not specified
Updated in this feed
4 Nov 2026, 17:56 UTC · Revision 1

Source evidence

mm: abort vma_modify() on merge out of memory failure

core-osv · Original source

Published 1 Apr 2025, 15:41 UTC

In the Linux kernel, the following vulnerability has been resolved: mm: abort vma_modify() on merge out of memory failure The remainder of vma_modify() relies upon the vmg state remaining pristine after a merge attempt. Usually this is the case, however in the one edge case scenario of a merge attempt failing not due to the specified range being unmergeable, but rather due to an out of memory error arising when attempting to commit the merge, this assumption becomes untrue. This results in vmg->start, end being modified, and thus the proceeding attempts to split the VMA will be done with invalid start/end values. Thankfully, it is likely practically impossible for us to hit this in reality, as it would require a maple tree node pre-allocation failure that would likely never happen due to it being 'too small to fail', i.e. the kernel would simply keep retrying reclaim until it succeeded. However, this scenario remains theoretically possible, and what we are doing here is wrong so we must correct it. The safest option is, when this scenario occurs, to simply give up the operation. If we cannot allocate memory to merge, then we cannot allocate memory to split either (perhaps moreso!). Any scenario where this would be happening would be under very extreme (likely fatal) memory pressure, so it's best we give up early. So there is no doubt it is appropriate to simply bail out in this scenario. However, in general we must if at all possible never assume VMG state is stable after a m

osv:CVE-2025-21932

Kernel

Fixed versions: 6.12.19, 6.13.7

Complete source record
{
  "id": "ae42fb842ede6afe81c2b681736759b5b567b24784b4d7d53d603e4eadf4908f",
  "url": "https://osv.dev/vulnerability/CVE-2025-21932",
  "method": "structured",
  "payload": {
    "kind": "advisory",
    "title": "mm: abort vma_modify() on merge out of memory failure",
    "summary": "In the Linux kernel, the following vulnerability has been resolved: mm: abort vma_modify() on merge out of memory failure The remainder of vma_modify() relies upon the vmg state remaining pristine after a merge attempt. Usually this is the case, however in the one edge case scenario of a merge attempt failing not due to the specified range being unmergeable, but rather due to an out of memory error arising when attempting to commit the merge, this assumption becomes untrue. This results in vmg->start, end being modified, and thus the proceeding attempts to split the VMA will be done with invalid start/end values. Thankfully, it is likely practically impossible for us to hit this in reality, as it would require a maple tree node pre-allocation failure that would likely never happen due to it being 'too small to fail', i.e. the kernel would simply keep retrying reclaim until it succeeded. However, this scenario remains theoretically possible, and what we are doing here is wrong so we must correct it. The safest option is, when this scenario occurs, to simply give up the operation. If we cannot allocate memory to merge, then we cannot allocate memory to split either (perhaps moreso!). Any scenario where this would be happening would be under very extreme (likely fatal) memory pressure, so it's best we give up early. So there is no doubt it is appropriate to simply bail out in this scenario. However, in general we must if at all possible never assume VMG state is stable after a m",
    "evidence": "osv:CVE-2025-21932",
    "products": [
      {
        "name": {
          "value": "Kernel",
          "evidence": "/affected/1/package/name"
        },
        "prerequisites": [],
        "fixed_versions": [
          {
            "value": "6.12.19",
            "evidence": "/affected/1/ranges"
          },
          {
            "value": "6.13.7",
            "evidence": "/affected/1/ranges"
          }
        ],
        "affected_versions": []
      }
    ],
    "severity": "high",
    "structured": {
      "id": "CVE-2025-21932",
      "aliases": [
        "CVE-2025-21932"
      ],
      "metrics": [
        {
          "type": "CVSS_V3",
          "score": "CVSS:3.1/AV:L/AC:H/PR:L/UI:N/S:U/C:H/I:H/A:H"
        }
      ],
      "affected": [
        {
          "ranges": [
            {
              "repo": "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git",
              "type": "GIT",
              "events": [
                {
                  "introduced": "2f1c6611b0a89afcb8641471af5f223c9caa01e0"
                },
                {
                  "fixed": "79636d2981b066acd945117387a9533f56411f6f"
                },
                {
                  "fixed": "53fd215f7886a1e8dea5a9ca1391dbb697fff601"
                },
                {
                  "fixed": "47b16d0462a460000b8f05dfb1292377ac48f3ca"
                }
              ]
            }
          ],
          "database_specific": {
            "source": "https://storage.googleapis.com/cve-osv-conversion/osv-output/CVE-2025-21932.json"
          }
        },
        {
          "ranges": [
            {
              "type": "ECOSYSTEM",
              "events": [
                {
                  "introduced": "6.12.0"
                },
                {
                  "fixed": "6.12.19"
                }
              ]
            },
            {
              "type": "ECOSYSTEM",
              "events": [
                {
                  "introduced": "6.13.0"
                },
                {
                  "fixed": "6.13.7"
                }
              ]
            }
          ],
          "package": {
            "name": "Kernel",
            "ecosystem": "Linux"
          },
          "database_specific": {
            "source": "https://storage.googleapis.com/cve-osv-conversion/osv-output/CVE-2025-21932.json"
          }
        }
      ],
      "modified": "2026-10-28T02:30:38.340774126Z",
      "provider": "osv",
      "references": [
        "https://git.kernel.org/stable/c/47b16d0462a460000b8f05dfb1292377ac48f3ca",
        "https://git.kernel.org/stable/c/53fd215f7886a1e8dea5a9ca1391dbb697fff601",
        "https://git.kernel.org/stable/c/79636d2981b066acd945117387a9533f56411f6f",
        "https://github.com/CVEProject/cvelistV5/tree/main/cves/2025/21xxx/CVE-2025-21932.json",
        "https://nvd.nist.gov/vuln/detail/CVE-2025-21932",
        "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git"
      ],
      "provider_metadata": {
        "cna_assigner": "Linux",
        "osv_generated_from": "https://github.com/CVEProject/cvelistV5/tree/main/cves/2025/21xxx/CVE-2025-21932.json"
      }
    },
    "related_cves": [
      {
        "value": "CVE-2025-21932",
        "evidence": "/id"
      }
    ],
    "security_relevant": true,
    "severity_evidence": "/severity/0/score"
  },
  "source_id": "core-osv",
  "document_id": 505540,
  "published_at": "2025-04-01T15:41:01.792+00:00"
}