{"resultsPerPage":1,"startIndex":0,"totalResults":1,"format":"NVD_CVE","version":"2.0","timestamp":"2026-05-13T06:04:28.798","vulnerabilities":[{"cve":{"id":"CVE-2025-21932","sourceIdentifier":"416baaa9-dc9f-4396-8d5f-8c081fb06d67","published":"2025-04-01T16:15:24.040","lastModified":"2025-10-30T19:45:34.203","vulnStatus":"Analyzed","cveTags":[],"descriptions":[{"lang":"en","value":"In the Linux kernel, the following vulnerability has been resolved:\n\nmm: abort vma_modify() on merge out of memory failure\n\nThe remainder of vma_modify() relies upon the vmg state remaining pristine\nafter a merge attempt.\n\nUsually this is the case, however in the one edge case scenario of a merge\nattempt failing not due to the specified range being unmergeable, but\nrather due to an out of memory error arising when attempting to commit the\nmerge, this assumption becomes untrue.\n\nThis results in vmg->start, end being modified, and thus the proceeding\nattempts to split the VMA will be done with invalid start/end values.\n\nThankfully, it is likely practically impossible for us to hit this in\nreality, as it would require a maple tree node pre-allocation failure that\nwould likely never happen due to it being 'too small to fail', i.e.  the\nkernel would simply keep retrying reclaim until it succeeded.\n\nHowever, this scenario remains theoretically possible, and what we are\ndoing here is wrong so we must correct it.\n\nThe safest option is, when this scenario occurs, to simply give up the\noperation.  If we cannot allocate memory to merge, then we cannot allocate\nmemory to split either (perhaps moreso!).\n\nAny scenario where this would be happening would be under very extreme\n(likely fatal) memory pressure, so it's best we give up early.\n\nSo there is no doubt it is appropriate to simply bail out in this\nscenario.\n\nHowever, in general we must if at all possible never assume VMG state is\nstable after a merge attempt, since merge operations update VMG fields. \nAs a result, additionally also make this clear by storing start, end in\nlocal variables.\n\nThe issue was reported originally by syzkaller, and by Brad Spengler (via\nan off-list discussion), and in both instances it manifested as a\ntriggering of the assert:\n\n\tVM_WARN_ON_VMG(start >= end, vmg);\n\nIn vma_merge_existing_range().\n\nIt seems at least one scenario in which this is occurring is one in which\nthe merge being attempted is due to an madvise() across multiple VMAs\nwhich looks like this:\n\n        start     end\n          |<------>|\n     |----------|------|\n     |   vma    | next |\n     |----------|------|\n\nWhen madvise_walk_vmas() is invoked, we first find vma in the above\n(determining prev to be equal to vma as we are offset into vma), and then\nenter the loop.\n\nWe determine the end of vma that forms part of the range we are\nmadvise()'ing by setting 'tmp' to this value:\n\n\t\t/* Here vma->vm_start <= start < (end|vma->vm_end) */\n\t\ttmp = vma->vm_end;\n\nWe then invoke the madvise() operation via visit(), letting prev get\nupdated to point to vma as part of the operation:\n\n\t\t/* Here vma->vm_start <= start < tmp <= (end|vma->vm_end). */\n\t\terror = visit(vma, &prev, start, tmp, arg);\n\nWhere the visit() function pointer in this instance is\nmadvise_vma_behavior().\n\nAs observed in syzkaller reports, it is ultimately madvise_update_vma()\nthat is invoked, calling vma_modify_flags_name() and vma_modify() in turn.\n\nThen, in vma_modify(), we attempt the merge:\n\n\tmerged = vma_merge_existing_range(vmg);\n\tif (merged)\n\t\treturn merged;\n\nWe invoke this with vmg->start, end set to start, tmp as such:\n\n        start  tmp\n          |<--->|\n     |----------|------|\n     |   vma    | next |\n     |----------|------|\n\nWe find ourselves in the merge right scenario, but the one in which we\ncannot remove the middle (we are offset into vma).\n\nHere we have a special case where vmg->start, end get set to perhaps\nunintuitive values - we intended to shrink the middle VMA and expand the\nnext.\n\nThis means vmg->start, end are set to...  vma->vm_start, start.\n\nNow the commit_merge() fails, and vmg->start, end are left like this. \nThis means we return to the rest of vma_modify() with vmg->start, end\n(here denoted as start', end') set as:\n\n  start' end'\n     |<-->|\n     |----------|------|\n     |   vma    | next |\n     |----------|------|\n\nSo we now erroneously try to split accordingly.  This is where the\nunfortunate\n---truncated---"},{"lang":"es","value":"En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: mm: abortar vma_modify() en caso de fallo de memoria insuficiente en la fusión. El resto de vma_modify() depende de que el estado de vmg permanezca intacto tras un intento de fusión. Normalmente, este es el caso; sin embargo, en el caso extremo de que un intento de fusión falle no porque el rango especificado no se pueda fusionar, sino debido a un error de memoria insuficiente al intentar confirmar la fusión, esta suposición se vuelve falsa. Esto da como resultado que vmg-&gt;start, end se modifique y, por lo tanto, los intentos posteriores de dividir el VMA se realizarán con valores de inicio/fin no válidos. Afortunadamente, es prácticamente imposible que logremos esto en la realidad, ya que requeriría un fallo de preasignación de nodos del árbol de maple que probablemente nunca ocurriría por ser \"demasiado pequeño para fallar\", es decir, el kernel simplemente seguiría reintentando la recuperación hasta que tuviera éxito. Sin embargo, este escenario sigue siendo teóricamente posible, y lo que estamos haciendo aquí es incorrecto, por lo que debemos corregirlo. La opción más segura, cuando ocurre este escenario, es simplemente abandonar la operación. Si no podemos asignar memoria para la fusión, tampoco podemos asignar memoria para la división (¡quizás incluso más!). Cualquier escenario donde esto ocurra estaría bajo una presión de memoria muy extrema (probablemente fatal), por lo que es mejor abandonar pronto. Por lo tanto, no hay duda de que es apropiado simplemente abandonar en este escenario. Sin embargo, en general, si es posible, nunca debemos asumir que el estado de VMG es estable después de un intento de fusión, ya que las operaciones de fusión actualizan los campos de VMG. Como resultado, también debemos aclarar esto almacenando inicio y fin en variables locales. El problema fue reportado originalmente por syzkaller y por Brad Spengler (a través de una discusión fuera de la lista), y en ambos casos se manifestó como una activación de la aserción: VM_WARN_ON_VMG(start &gt;= end, vmg); In vma_merge_existing_range(). Parece que al menos un escenario en el que esto ocurre es uno en el que la fusión que se intenta se debe a una función madvise() en múltiples VMA, con este aspecto: inicio fin |&lt;------&gt;| |----------|------| | vma | siguiente | |----------|------| Cuando se invoca madvise_walk_vmas(), primero encontramos vma en lo anterior (determinando que prev sea igual a vma, ya que estamos desplazados hacia vma) y luego entramos en el bucle. Determinamos el final de vma que forma parte del rango que estamos ejecutando con madvise() estableciendo 'tmp' en este valor: /* Aquí vma-&gt;vm_start &lt;= start &lt; (end|vma-&gt;vm_end) */ tmp = vma-&gt;vm_end; Luego invocamos la operación madvise() a través de visit(), permitiendo que prev se actualice para apuntar a vma como parte de la operación: /* Aquí vma-&gt;vm_start &lt;= start &lt; tmp &lt;= (end|vma-&gt;vm_end). */ error = visit(vma, &amp;prev, start, tmp, arg); Donde el puntero de la función visit() en esta instancia es madvise_vma_behavior(). Como se observa en los informes de syzkaller, en última instancia es madvise_update_vma() el que se invoca, llamando a vma_modify_flags_name() y vma_modify() a su vez. Luego, en vma_modify(), intentamos la fusión: merged = vma_merge_existing_range(vmg); if (merged) return merged; Invocamos esto con vmg-&gt;start, end establecido en start, tmp como tal: start tmp |&lt;---&gt;| |----------|------| | vma | next | |----------|------| Nos encontramos en el escenario correcto de fusión, pero en el que no podemos eliminar la parte central (estamos desplazados hacia vma). Aquí tenemos un caso especial donde vmg-&gt;start, end se establecen en valores quizás poco intuitivos: pretendíamos reducir la VMA central y expandir la siguiente. Esto significa que vmg-&gt;start, end se establecen en... vma-&gt;vm_start, start. Ahora, commit_merge() falla y vmg-&gt;start, end se mantienen así. Esto significa que volvemos al resto de vma_modify() ---truncated---"}],"metrics":{"cvssMetricV31":[{"source":"nvd@nist.gov","type":"Primary","cvssData":{"version":"3.1","vectorString":"CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H","baseScore":5.5,"baseSeverity":"MEDIUM","attackVector":"LOCAL","attackComplexity":"LOW","privilegesRequired":"LOW","userInteraction":"NONE","scope":"UNCHANGED","confidentialityImpact":"NONE","integrityImpact":"NONE","availabilityImpact":"HIGH"},"exploitabilityScore":1.8,"impactScore":3.6}]},"weaknesses":[{"source":"nvd@nist.gov","type":"Primary","description":[{"lang":"en","value":"NVD-CWE-noinfo"}]}],"configurations":[{"nodes":[{"operator":"OR","negate":false,"cpeMatch":[{"vulnerable":true,"criteria":"cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*","versionStartIncluding":"6.12","versionEndExcluding":"6.12.19","matchCriteriaId":"EC0CC37A-843F-489C-B8A2-45012E0AF641"},{"vulnerable":true,"criteria":"cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*","versionStartIncluding":"6.13","versionEndExcluding":"6.13.7","matchCriteriaId":"842F5A44-3E71-4546-B4FD-43B0ACE3F32B"},{"vulnerable":true,"criteria":"cpe:2.3:o:linux:linux_kernel:6.14:rc1:*:*:*:*:*:*","matchCriteriaId":"186716B6-2B66-4BD0-852E-D48E71C0C85F"},{"vulnerable":true,"criteria":"cpe:2.3:o:linux:linux_kernel:6.14:rc2:*:*:*:*:*:*","matchCriteriaId":"0D3E781C-403A-498F-9DA9-ECEE50F41E75"},{"vulnerable":true,"criteria":"cpe:2.3:o:linux:linux_kernel:6.14:rc3:*:*:*:*:*:*","matchCriteriaId":"66619FB8-0AAF-4166-B2CF-67B24143261D"},{"vulnerable":true,"criteria":"cpe:2.3:o:linux:linux_kernel:6.14:rc4:*:*:*:*:*:*","matchCriteriaId":"D3D6550E-6679-4560-902D-AF52DCFE905B"},{"vulnerable":true,"criteria":"cpe:2.3:o:linux:linux_kernel:6.14:rc5:*:*:*:*:*:*","matchCriteriaId":"45B90F6B-BEC7-4D4E-883A-9DBADE021750"}]}]}],"references":[{"url":"https://git.kernel.org/stable/c/47b16d0462a460000b8f05dfb1292377ac48f3ca","source":"416baaa9-dc9f-4396-8d5f-8c081fb06d67","tags":["Patch"]},{"url":"https://git.kernel.org/stable/c/53fd215f7886a1e8dea5a9ca1391dbb697fff601","source":"416baaa9-dc9f-4396-8d5f-8c081fb06d67","tags":["Patch"]},{"url":"https://git.kernel.org/stable/c/79636d2981b066acd945117387a9533f56411f6f","source":"416baaa9-dc9f-4396-8d5f-8c081fb06d67","tags":["Patch"]}]}}]}