{"resultsPerPage":1,"startIndex":0,"totalResults":1,"format":"NVD_CVE","version":"2.0","timestamp":"2026-05-15T01:40:39.923","vulnerabilities":[{"cve":{"id":"CVE-2026-23077","sourceIdentifier":"416baaa9-dc9f-4396-8d5f-8c081fb06d67","published":"2026-02-04T17:16:18.443","lastModified":"2026-04-03T14:16:22.800","vulnStatus":"Modified","cveTags":[],"descriptions":[{"lang":"en","value":"In the Linux kernel, the following vulnerability has been resolved:\n\nmm/vma: fix anon_vma UAF on mremap() faulted, unfaulted merge\n\nPatch series \"mm/vma: fix anon_vma UAF on mremap() faulted, unfaulted\nmerge\", v2.\n\nCommit 879bca0a2c4f (\"mm/vma: fix incorrectly disallowed anonymous VMA\nmerges\") introduced the ability to merge previously unavailable VMA merge\nscenarios.\n\nHowever, it is handling merges incorrectly when it comes to mremap() of a\nfaulted VMA adjacent to an unfaulted VMA.  The issues arise in three\ncases:\n\n1. Previous VMA unfaulted:\n\n              copied -----|\n                          v\n\t|-----------|.............|\n\t| unfaulted |(faulted VMA)|\n\t|-----------|.............|\n\t     prev\n\n2. Next VMA unfaulted:\n\n              copied -----|\n                          v\n\t            |.............|-----------|\n\t            |(faulted VMA)| unfaulted |\n                    |.............|-----------|\n\t\t                      next\n\n3. Both adjacent VMAs unfaulted:\n\n              copied -----|\n                          v\n\t|-----------|.............|-----------|\n\t| unfaulted |(faulted VMA)| unfaulted |\n\t|-----------|.............|-----------|\n\t     prev                      next\n\nThis series fixes each of these cases, and introduces self tests to assert\nthat the issues are corrected.\n\nI also test a further case which was already handled, to assert that my\nchanges continues to correctly handle it:\n\n4. prev unfaulted, next faulted:\n\n              copied -----|\n                          v\n\t|-----------|.............|-----------|\n\t| unfaulted |(faulted VMA)|  faulted  |\n\t|-----------|.............|-----------|\n\t     prev                      next\n\nThis bug was discovered via a syzbot report, linked to in the first patch\nin the series, I confirmed that this series fixes the bug.\n\nI also discovered that we are failing to check that the faulted VMA was\nnot forked when merging a copied VMA in cases 1-3 above, an issue this\nseries also addresses.\n\nI also added self tests to assert that this is resolved (and confirmed\nthat the tests failed prior to this).\n\nI also cleaned up vma_expand() as part of this work, renamed\nvma_had_uncowed_parents() to vma_is_fork_child() as the previous name was\nunduly confusing, and simplified the comments around this function.\n\n\nThis patch (of 4):\n\nCommit 879bca0a2c4f (\"mm/vma: fix incorrectly disallowed anonymous VMA\nmerges\") introduced the ability to merge previously unavailable VMA merge\nscenarios.\n\nThe key piece of logic introduced was the ability to merge a faulted VMA\nimmediately next to an unfaulted VMA, which relies upon dup_anon_vma() to\ncorrectly handle anon_vma state.\n\nIn the case of the merge of an existing VMA (that is changing properties\nof a VMA and then merging if those properties are shared by adjacent\nVMAs), dup_anon_vma() is invoked correctly.\n\nHowever in the case of the merge of a new VMA, a corner case peculiar to\nmremap() was missed.\n\nThe issue is that vma_expand() only performs dup_anon_vma() if the target\n(the VMA that will ultimately become the merged VMA): is not the next VMA,\ni.e.  the one that appears after the range in which the new VMA is to be\nestablished.\n\nA key insight here is that in all other cases other than mremap(), a new\nVMA merge either expands an existing VMA, meaning that the target VMA will\nbe that VMA, or would have anon_vma be NULL.\n\nSpecifically:\n\n* __mmap_region() - no anon_vma in place, initial mapping.\n* do_brk_flags() - expanding an existing VMA.\n* vma_merge_extend() - expanding an existing VMA.\n* relocate_vma_down() - no anon_vma in place, initial mapping.\n\nIn addition, we are in the unique situation of needing to duplicate\nanon_vma state from a VMA that is neither the previous or next VMA being\nmerged with.\n\ndup_anon_vma() deals exclusively with the target=unfaulted, src=faulted\ncase.  This leaves four possibilities, in each case where the copied VMA\nis faulted:\n\n1. Previous VMA unfaulted:\n\n              copied -----|\n                       \n---truncated---"},{"lang":"es","value":"En el kernel de Linux, la siguiente vulnerabilidad ha sido resuelta:  mm/vma: corrige UAF de anon_vma en mremap() con fusión de VMA faulted y unfaulted  Serie de parches \"mm/vma: corrige UAF de anon_vma en mremap() con fusión de VMA faulted y unfaulted\", v2.  El commit 879bca0a2c4f ('mm/vma: corrige fusiones de VMA anónimas incorrectamente denegadas') introdujo la capacidad de fusionar escenarios de fusión de VMA previamente no disponibles.  Sin embargo, está manejando las fusiones incorrectamente cuando se trata de mremap() de un VMA faulted adyacente a un VMA unfaulted. Los problemas surgen en tres casos:  1. VMA anterior unfaulted:copiado -----|           v  .............|  | unfaulted |(VMA faulted)|  .............|       anterior  2. Siguiente VMA unfaulted:copiado -----|           v                            |(VMA faulted)| unfaulted |              siguiente  3. Ambos VMA adyacentes unfaulted:copiado -----|           v  .............  | unfaulted |(VMA faulted)| unfaulted |  .............       anterior  siguiente  Esta serie corrige cada uno de estos casos e introduce auto-pruebas para afirmar que los problemas están corregidos.  También pruebo un caso adicional que ya estaba manejado, para afirmar que mis cambios continúan manejándolo correctamente:  4. anterior unfaulted, siguiente faulted:copiado -----| v  .............  | unfaulted |(VMA faulted)|  faulted  |  .............       anterior  siguiente  Este error fue descubierto a través de un informe de syzbot, enlazado en el primer parche de la serie, confirmé que esta serie corrige el error.  También descubrí que no estamos verificando que el VMA faulted no fue bifurcado al fusionar un VMA copiado en los casos 1-3 anteriores, un problema que esta serie también aborda.  También agregué auto-pruebas para afirmar que esto está resuelto (y confirmé que las pruebas fallaron antes de esto).  También limpié vma_expand() como parte de este trabajo, renombré vma_had_uncowed_parents() a vma_is_fork_child() ya que el nombre anterior era indebidamente confuso, y simplifiqué los comentarios alrededor de esta función.   Este parche (de 4):  El commit 879bca0a2c4f ('mm/vma: corrige fusiones de VMA anónimas incorrectamente denegadas') introdujo la capacidad de fusionar escenarios de fusión de VMA previamente no disponibles.  La pieza clave de lógica introducida fue la capacidad de fusionar un VMA faulted inmediatamente adyacente a un VMA unfaulted, lo cual se basa en dup_anon_vma() para manejar correctamente el estado de anon_vma.  En el caso de la fusión de un VMA existente (es decir, cambiando propiedades de un VMA y luego fusionando si esas propiedades son compartidas por VMA adyacentes), dup_anon_vma() se invoca correctamente.  Sin embargo, en el caso de la fusión de un nuevo VMA, se pasó por alto un caso particular peculiar de mremap().  El problema es que vma_expand() solo realiza dup_anon_vma() si el objetivo (el VMA que finalmente se convertirá en el VMA fusionado): no es el siguiente VMA, es decir, el que aparece después del rango en el que se establecerá el nuevo VMA.  Una idea clave aquí es que en todos los demás casos, aparte de mremap(), una nueva fusión de VMA o bien expande un VMA existente, lo que significa que el VMA objetivo será ese VMA, o anon_vma sería NULL.  Específicamente:  * __mmap_region() - no hay anon_vma en su lugar, mapeo inicial. * do_brk_flags() - expandiendo un VMA existente. * vma_merge_extend() - expandiendo un VMA existente. * relocate_vma_down() - no hay anon_vma en su lugar, mapeo inicial.  Además, nos encontramos en la situación única de necesitar duplicar el estado de anon_vma de un VMA que no es ni el VMA anterior ni el siguiente con el que se está fusionando.  dup_anon_vma() se ocupa exclusivamente del caso objetivo=unfaulted, fuente=faulted. Esto deja cuatro posibilidades, en cada caso donde el VMA copiado es faulted:  1. VMA anterior unfaulted:copiado -----|         ---truncado---"}],"metrics":{"cvssMetricV31":[{"source":"416baaa9-dc9f-4396-8d5f-8c081fb06d67","type":"Secondary","cvssData":{"version":"3.1","vectorString":"CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H","baseScore":7.8,"baseSeverity":"HIGH","attackVector":"LOCAL","attackComplexity":"LOW","privilegesRequired":"LOW","userInteraction":"NONE","scope":"UNCHANGED","confidentialityImpact":"HIGH","integrityImpact":"HIGH","availabilityImpact":"HIGH"},"exploitabilityScore":1.8,"impactScore":5.9},{"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:H/I:H/A:H","baseScore":7.8,"baseSeverity":"HIGH","attackVector":"LOCAL","attackComplexity":"LOW","privilegesRequired":"LOW","userInteraction":"NONE","scope":"UNCHANGED","confidentialityImpact":"HIGH","integrityImpact":"HIGH","availabilityImpact":"HIGH"},"exploitabilityScore":1.8,"impactScore":5.9}]},"weaknesses":[{"source":"nvd@nist.gov","type":"Primary","description":[{"lang":"en","value":"CWE-416"}]}],"configurations":[{"nodes":[{"operator":"OR","negate":false,"cpeMatch":[{"vulnerable":true,"criteria":"cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*","versionStartIncluding":"6.16","versionEndExcluding":"6.18.8","matchCriteriaId":"467E1359-7F6A-4790-AC45-172024944460"},{"vulnerable":true,"criteria":"cpe:2.3:o:linux:linux_kernel:6.19:rc1:*:*:*:*:*:*","matchCriteriaId":"17B67AA7-40D6-4AFA-8459-F200F3D7CFD1"},{"vulnerable":true,"criteria":"cpe:2.3:o:linux:linux_kernel:6.19:rc2:*:*:*:*:*:*","matchCriteriaId":"C47E4CC9-C826-4FA9-B014-7FE3D9B318B2"},{"vulnerable":true,"criteria":"cpe:2.3:o:linux:linux_kernel:6.19:rc3:*:*:*:*:*:*","matchCriteriaId":"F71D92C0-C023-48BD-B3B6-70B638EEE298"},{"vulnerable":true,"criteria":"cpe:2.3:o:linux:linux_kernel:6.19:rc4:*:*:*:*:*:*","matchCriteriaId":"13580667-0A98-40CC-B29F-D12790B91BDB"},{"vulnerable":true,"criteria":"cpe:2.3:o:linux:linux_kernel:6.19:rc5:*:*:*:*:*:*","matchCriteriaId":"CAD1FED7-CF48-47BF-AC7D-7B6FA3C065FC"}]}]}],"references":[{"url":"https://git.kernel.org/stable/c/61f67c230a5e7c741c352349ea80147fbe65bfae","source":"416baaa9-dc9f-4396-8d5f-8c081fb06d67","tags":["Patch"]},{"url":"https://git.kernel.org/stable/c/a4d9dbfc1bab16e25fefd34b5e537a46bed8fc96","source":"416baaa9-dc9f-4396-8d5f-8c081fb06d67","tags":["Patch"]}]}}]}