CVE-2026-23077

Estado: ModificadaAlta (7.8)—

In the Linux kernel, the following vulnerability has been resolved:

mm/vma: fix anon_vma UAF on mremap() faulted, unfaulted merge

Patch series "mm/vma: fix anon_vma UAF on mremap() faulted, unfaulted merge", v2.

Commit 879bca0a2c4f ("mm/vma: fix incorrectly disallowed anonymous VMA merges") introduced the ability to merge previously unavailable VMA merge scenarios.

However, it is handling merges incorrectly when it comes to mremap() of a faulted VMA adjacent to an unfaulted VMA. The issues arise in three cases:

1. Previous VMA unfaulted:

2. Next VMA unfaulted:

3. Both adjacent VMAs unfaulted:

This series fixes each of these cases, and introduces self tests to assert that the issues are corrected.

Leer descripción completaMostrar menos

I also test a further case which was already handled, to assert that my changes continues to correctly handle it:

4. prev unfaulted, next faulted:

This bug was discovered via a syzbot report, linked to in the first patch in the series, I confirmed that this series fixes the bug.

I also discovered that we are failing to check that the faulted VMA was not forked when merging a copied VMA in cases 1-3 above, an issue this series also addresses.

I also added self tests to assert that this is resolved (and confirmed that the tests failed prior to this).

I also cleaned up vma_expand() as part of this work, renamed vma_had_uncowed_parents() to vma_is_fork_child() as the previous name was unduly confusing, and simplified the comments around this function.

This patch (of 4):

Commit 879bca0a2c4f ("mm/vma: fix incorrectly disallowed anonymous VMA merges") introduced the ability to merge previously unavailable VMA merge scenarios.

The key piece of logic introduced was the ability to merge a faulted VMA immediately next to an unfaulted VMA, which relies upon dup_anon_vma() to correctly handle anon_vma state.

In the case of the merge of an existing VMA (that is changing properties of a VMA and then merging if those properties are shared by adjacent VMAs), dup_anon_vma() is invoked correctly.

However in the case of the merge of a new VMA, a corner case peculiar to mremap() was missed.

The issue is that vma_expand() only performs dup_anon_vma() if the target (the VMA that will ultimately become the merged VMA): is not the next VMA, i.e. the one that appears after the range in which the new VMA is to be established.

A key insight here is that in all other cases other than mremap(), a new VMA merge either expands an existing VMA, meaning that the target VMA will be that VMA, or would have anon_vma be NULL.

Specifically:

* __mmap_region() - no anon_vma in place, initial mapping. * do_brk_flags() - expanding an existing VMA. * vma_merge_extend() - expanding an existing VMA. * relocate_vma_down() - no anon_vma in place, initial mapping.

In addition, we are in the unique situation of needing to duplicate anon_vma state from a VMA that is neither the previous or next VMA being merged with.

dup_anon_vma() deals exclusively with the target=unfaulted, src=faulted case. This leaves four possibilities, in each case where the copied VMA is faulted:

1. Previous VMA unfaulted:

---truncated---

Detalles técnicos trazas, registros y código del informe original

              copied -----|
                          v
	|-----------|.............|
	| unfaulted |(faulted VMA)|
	|-----------|.............|
	     prev

              copied -----|
                          v
	            |.............|-----------|
	            |(faulted VMA)| unfaulted |
                    |.............|-----------|
		                      next

              copied -----|
                          v
	|-----------|.............|-----------|
	| unfaulted |(faulted VMA)| unfaulted |
	|-----------|.............|-----------|
	     prev                      next

              copied -----|
                          v
	|-----------|.............|-----------|
	| unfaulted |(faulted VMA)|  faulted  |
	|-----------|.............|-----------|
	     prev                      next

              copied -----|

CVSS

Versión: 3.1
Vector: CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H
Puntuación base: 7.8

Probabilidad de explotación (EPSS)

Probabilidad de explotación en los próximos 30 días: 0.16%
Percentil entre todas las CVEs puntuadas: 4
Fecha de la puntuación: 6/10/2026

EPSS (Exploit Prediction Scoring System, de FIRST) estima la probabilidad de que una vulnerabilidad sea explotada en 30 días. Complementa a CVSS (impacto) y a CISA KEV (explotación confirmada).

🎯 Técnicas ATT&CK

Cómo se explota esta vulnerabilidad y qué consigue el atacante, en el lenguaje de MITRE ATT&CK.

ExplotaciónT1068 Exploitation for Privilege Escalationprivilege escalation75 %
Impacto principalT1059 Command and Scripting Interpreterexecution60 %

CVE en kernel Linux con AV:L/PR:L/UI:N y CWE-416 (UAF). Acceso local con privilegios permite escalada o ejecución de código. La pista sugiere T1068 para explotación local.

Inferido por nuestro agente de análisis a partir de la descripción oficial, el vector CVSS y la CWE, y comprobado por un supervisor. Puede contener errores.

🛡️ Mitigaciones ATT&CK que cubren estas técnicas

Execution Prevention Threat Intelligence Program Restrict Web-Based Content Privileged Account Management Limit Software Installation Behavior Prevention on Endpoint

Tecnologías afectadas (1)

Linux — Linux Kernel

CWE

CWE-416

Referencias

JSON original (NVD)

Mostrar

{
  "id": "CVE-2026-23077",
  "cveTags": [],
  "metrics": {
    "cvssMetricV31": [
      {
        "type": "Secondary",
        "source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
        "cvssData": {
          "scope": "UNCHANGED",
          "version": "3.1",
          "baseScore": 7.8,
          "attackVector": "LOCAL",
          "baseSeverity": "HIGH",
          "vectorString": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H",
          "integrityImpact": "HIGH",
          "userInteraction": "NONE",
          "attackComplexity": "LOW",
          "availabilityImpact": "HIGH",
          "privilegesRequired": "LOW",
          "confidentialityImpact": "HIGH"
        },
        "impactScore": 5.9,
        "exploitabilityScore": 1.8
      },
      {
        "type": "Primary",
        "source": "nvd@nist.gov",
        "cvssData": {
          "scope": "UNCHANGED",
          "version": "3.1",
          "baseScore": 7.8,
          "attackVector": "LOCAL",
          "baseSeverity": "HIGH",
          "vectorString": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H",
          "integrityImpact": "HIGH",
          "userInteraction": "NONE",
          "attackComplexity": "LOW",
          "availabilityImpact": "HIGH",
          "privilegesRequired": "LOW",
          "confidentialityImpact": "HIGH"
        },
        "impactScore": 5.9,
        "exploitabilityScore": 1.8
      }
    ]
  },
  "affected": [
    {
      "source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
      "affectedData": [
        {
          "repo": "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git",
          "vendor": "Linux",
          "product": "Linux",
          "versions": [
            {
              "status": "affected",
              "version": "879bca0a2c4f40b08d09a95a2a0c3c6513060b5c",
              "lessThan": "a4d9dbfc1bab16e25fefd34b5e537a46bed8fc96",
              "versionType": "git"
            },
            {
              "status": "affected",
              "version": "879bca0a2c4f40b08d09a95a2a0c3c6513060b5c",
              "lessThan": "61f67c230a5e7c741c352349ea80147fbe65bfae",
              "versionType": "git"
            }
          ],
          "programFiles": [
            "mm/vma.c",
            "mm/vma.h"
          ],
          "defaultStatus": "unaffected"
        },
        {
          "repo": "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git",
          "vendor": "Linux",
          "product": "Linux",
          "versions": [
            {
              "status": "affected",
              "version": "6.16"
            },
            {
              "status": "unaffected",
              "version": "0",
              "lessThan": "6.16",
              "versionType": "semver"
            },
            {
              "status": "unaffected",
              "version": "6.18.8",
              "versionType": "semver",
              "lessThanOrEqual": "6.18.*"
            },
            {
              "status": "unaffected",
              "version": "6.19",
              "versionType": "original_commit_for_fix",
              "lessThanOrEqual": "*"
            }
          ],
          "programFiles": [
            "mm/vma.c",
            "mm/vma.h"
          ],
          "defaultStatus": "affected"
        }
      ]
    }
  ],
  "published": "2026-02-04T17:16:18.443",
  "references": [
    {
      "url": "https://git.kernel.org/stable/c/61f67c230a5e7c741c352349ea80147fbe65bfae",
      "tags": [
        "Patch"
      ],
      "source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67"
    },
    {
      "url": "https://git.kernel.org/stable/c/a4d9dbfc1bab16e25fefd34b5e537a46bed8fc96",
      "tags": [
        "Patch"
      ],
      "source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67"
    }
  ],
  "vulnStatus": "Modified",
  "weaknesses": [
    {
      "type": "Primary",
      "source": "nvd@nist.gov",
      "description": [
        {
          "lang": "en",
          "value": "CWE-416"
        }
      ]
    }
  ],
  "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---"
    }
  ],
  "lastModified": "2026-06-17T10:20:49.473",
  "configurations": [
    {
      "nodes": [
        {
          "negate": false,
          "cpeMatch": [
            {
              "criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
              "vulnerable": true,
              "matchCriteriaId": "467E1359-7F6A-4790-AC45-172024944460",
              "versionEndExcluding": "6.18.8",
              "versionStartIncluding": "6.16"
            },
            {
              "criteria": "cpe:2.3:o:linux:linux_kernel:6.19:rc1:*:*:*:*:*:*",
              "vulnerable": true,
              "matchCriteriaId": "17B67AA7-40D6-4AFA-8459-F200F3D7CFD1"
            },
            {
              "criteria": "cpe:2.3:o:linux:linux_kernel:6.19:rc2:*:*:*:*:*:*",
              "vulnerable": true,
              "matchCriteriaId": "C47E4CC9-C826-4FA9-B014-7FE3D9B318B2"
            },
            {
              "criteria": "cpe:2.3:o:linux:linux_kernel:6.19:rc3:*:*:*:*:*:*",
              "vulnerable": true,
              "matchCriteriaId": "F71D92C0-C023-48BD-B3B6-70B638EEE298"
            },
            {
              "criteria": "cpe:2.3:o:linux:linux_kernel:6.19:rc4:*:*:*:*:*:*",
              "vulnerable": true,
              "matchCriteriaId": "13580667-0A98-40CC-B29F-D12790B91BDB"
            },
            {
              "criteria": "cpe:2.3:o:linux:linux_kernel:6.19:rc5:*:*:*:*:*:*",
              "vulnerable": true,
              "matchCriteriaId": "CAD1FED7-CF48-47BF-AC7D-7B6FA3C065FC"
            }
          ],
          "operator": "OR"
        }
      ]
    }
  ],
  "sourceIdentifier": "416baaa9-dc9f-4396-8d5f-8c081fb06d67"
}