CVE-2025-21932
published 2025-04-01CVE-2025-21932: 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…
PriorityP420medium5.5CVSS 3.1
AVLACLPRLUINSUCNINAH
EPSS
0.19%
9.1th percentile
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 merge attempt, since merge operations update VMG fields.
As a result, additionally also make this clear by storing start, end in
local variables.
The issue was reported originally by syzkaller, and by Brad Spengler (via
an off-list discussion), and in both instances it manifested as a
triggering of the assert:
VM_WARN_ON_VMG(start >= end, vmg);
In vma_merge_existing_range().
It seems at least one scenario in which this is occurring is one in which
the merge being attempted is due to
Affected
14 ranges
| Vendor | Product | Version range | Fixed in |
|---|---|---|---|
| debian | linux | < linux 6.12.19-1 (forky) | linux 6.12.19-1 (forky) |
| linux | linux | — | — |
| linux | linux | >= 2f1c6611b0a89afcb8641471af5f223c9caa01e0 < 79636d2981b066acd945117387a9533f56411f6f | 79636d2981b066acd945117387a9533f56411f6f |
| linux | linux | >= 2f1c6611b0a89afcb8641471af5f223c9caa01e0 < 53fd215f7886a1e8dea5a9ca1391dbb697fff601 | 53fd215f7886a1e8dea5a9ca1391dbb697fff601 |
| linux | linux | >= 2f1c6611b0a89afcb8641471af5f223c9caa01e0 < 47b16d0462a460000b8f05dfb1292377ac48f3ca | 47b16d0462a460000b8f05dfb1292377ac48f3ca |
| linux | linux_kernel | — | — |
| linux | linux_kernel | — | — |
| linux | linux_kernel | — | — |
| linux | linux_kernel | — | — |
| linux | linux_kernel | — | — |
| linux | linux_kernel | >= 0 < 6.12.19-1 | 6.12.19-1 |
| linux | linux_kernel | >= 0 < 6.12.19-1 | 6.12.19-1 |
| linux | linux_kernel | >= 6.12 < 6.12.19 | 6.12.19 |
| linux | linux_kernel | >= 6.13 < 6.13.7 | 6.13.7 |
CVSS provenance
nvdv3.15.5MEDIUMCVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
osv5.5MEDIUM
vendor_debian5.5LOW
vendor_redhat5.5MEDIUM
Stop checking back — get the weekly exploitation signal.
Every Monday: what got weaponized or added to CISA KEV in the last seven days — each CVE cross-linked to its PoC, Nuclei template, and detection rule. Free, one email a week, unsubscribe in one click.
Red Hat
kernel: mm: abort vma_modify() on merge out of memory failure
vendor_redhat·2025-04-01·CVSS 5.5
CVE-2025-21932 [MEDIUM] kernel: mm: abort vma_modify() on merge out of memory failure
kernel: mm: abort vma_modify() on merge out of memory failure
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
Debian
CVE-2025-21932: linux - In the Linux kernel, the following vulnerability has been resolved: mm: abort v...
vendor_debian·2025·CVSS 5.5
CVE-2025-21932 [MEDIUM] CVE-2025-21932: linux - In the Linux kernel, the following vulnerability has been resolved: mm: abort v...
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 i
VulDB
Linux Kernel up to 6.12.18/6.13.6 mm vma_modify allocation of resources (WID-SEC-2025-0683)
vuldb·2026-07-31·CVSS 5.5
CVE-2025-21932 [MEDIUM] Linux Kernel up to 6.12.18/6.13.6 mm vma_modify allocation of resources (WID-SEC-2025-0683)
A vulnerability, which was classified as problematic, was found in Linux Kernel up to 6.12.18/6.13.6. Impacted is the function vma_modify of the component mm. Executing a manipulation can lead to allocation of resources.
This vulnerability is handled as CVE-2025-21932. The attack can only be done within the local network. There is not any exploit available.
You should upgrade the affected component.
GHSA
GHSA-fcgh-gjcg-cmc2: In the Linux kernel, the following vulnerability has been resolved:
mm: abort vma_modify() on merge out of memory failure
The remainder of vma_modif
ghsa_unreviewed·2025-04-01
CVE-2025-21932 [MEDIUM] GHSA-fcgh-gjcg-cmc2: In the Linux kernel, the following vulnerability has been resolved:
mm: abort vma_modify() on merge out of memory failure
The remainder of vma_modif
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
OSV
CVE-2025-21932: 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(
osv·2025-04-01·CVSS 5.5
CVE-2025-21932 [MEDIUM] CVE-2025-21932: 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(
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 i
No detection rules found.
No public exploits indexed.
2025-04-01
Published