« Volver al listado

CVE-2022-50014

Estado: ModificadaAlta (7)—

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

mm/gup: fix FOLL_FORCE COW security issue and remove FOLL_COW

Ever since the Dirty COW (CVE-2016-5195) security issue happened, we know that FOLL_FORCE can be possibly dangerous, especially if there are races that can be exploited by user space.

Right now, it would be sufficient to have some code that sets a PTE of a R/O-mapped shared page dirty, in order for it to erroneously become writable by FOLL_FORCE. The implications of setting a write-protected PTE dirty might not be immediately obvious to everyone.

And in fact ever since commit 9ae0f87d009c ("mm/shmem: unconditionally set pte dirty in mfill_atomic_install_pte"), we can use UFFDIO_CONTINUE to map a shmem page R/O while marking the pte dirty.

Leer descripción completaMostrar menos

This can be used by unprivileged user space to modify tmpfs/shmem file content even if the user does not have write permissions to the file, and to bypass memfd write sealing -- Dirty COW restricted to tmpfs/shmem (CVE-2022-2590).

To fix such security issues for good, the insight is that we really only need that fancy retry logic (FOLL_COW) for COW mappings that are not writable (!VM_WRITE). And in a COW mapping, we really only broke COW if we have an exclusive anonymous page mapped. If we have something else mapped, or the mapped anonymous page might be shared (!PageAnonExclusive), we have to trigger a write fault to break COW. If we don't find an exclusive anonymous page when we retry, we have to trigger COW breaking once again because something intervened.

Let's move away from this mandatory-retry + dirty handling and rely on our PageAnonExclusive() flag for making a similar decision, to use the same COW logic as in other kernel parts here as well. In case we stumble over a PTE in a COW mapping that does not map an exclusive anonymous page, COW was not properly broken and we have to trigger a fake write-fault to break COW.

Just like we do in can_change_pte_writable() added via commit 64fe24a3e05e ("mm/mprotect: try avoiding write faults for exclusive anonymous pages when changing protection") and commit 76aefad628aa ("mm/mprotect: fix soft-dirty check in can_change_pte_writable()"), take care of softdirty and uffd-wp manually.

For example, a write() via /proc/self/mem to a uffd-wp-protected range has to fail instead of silently granting write access and bypassing the userspace fault handler. Note that FOLL_FORCE is not only used for debug access, but also triggered by applications without debug intentions, for example, when pinning pages via RDMA.

This fixes CVE-2022-2590. Note that only x86_64 and aarch64 are affected, because only those support CONFIG_HAVE_ARCH_USERFAULTFD_MINOR.

Fortunately, FOLL_COW is no longer required to handle FOLL_FORCE. So let's just get rid of it.

Thanks to Nadav Amit for pointing out that the pte_dirty() check in FOLL_FORCE code is problematic and might be exploitable.

Detalles técnicos trazas, registros y código del informe original
Note 1: We don't check for the PTE being dirty because it doesn't matter
	for making a "was COWed" decision anymore, and whoever modifies the
	page has to set the page dirty either way.

Note 2: Kernels before extended uffd-wp support and before
	PageAnonExclusive (< 5.19) can simply revert the problematic
	commit instead and be safe regarding UFFDIO_CONTINUE. A backport to
	v5.19 requires minor adjustments due to lack of
	vma_soft_dirty_enabled().

CVSS

Probabilidad de explotación (EPSS)

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.

AV:L/PR:L permite escalada local. Unprivileged user puede explotar FOLL_FORCE+UFFDIO_CONTINUE para escribir en páginas protegidas (tmpfs/shmem) y modificar contenido sin permisos, rompiendo limitaciones de memoria.

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

Threat Intelligence ProgramRestrict File and Directory PermissionsRemote Data StorageExecution PreventionEncrypt Sensitive InformationApplication Isolation and Sandboxing

Tecnologías afectadas (1)

Linux — Linux Kernel

CWE

Referencias

JSON original (NVD)

Mostrar
{
  "id": "CVE-2022-50014",
  "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,
          "attackVector": "LOCAL",
          "baseSeverity": "HIGH",
          "vectorString": "CVSS:3.1/AV:L/AC:H/PR:L/UI:N/S:U/C:H/I:H/A:H",
          "integrityImpact": "HIGH",
          "userInteraction": "NONE",
          "attackComplexity": "HIGH",
          "availabilityImpact": "HIGH",
          "privilegesRequired": "LOW",
          "confidentialityImpact": "HIGH"
        },
        "impactScore": 5.9,
        "exploitabilityScore": 1
      }
    ]
  },
  "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": "9ae0f87d009ca6c4aab2882641ddfc319727e3db",
              "lessThan": "9def52eb10baab3b700858003d462fcf17d62873",
              "versionType": "git"
            },
            {
              "status": "affected",
              "version": "9ae0f87d009ca6c4aab2882641ddfc319727e3db",
              "lessThan": "5535be3099717646781ce1540cf725965d680e7b",
              "versionType": "git"
            }
          ],
          "programFiles": [
            "include/linux/mm.h",
            "mm/gup.c",
            "mm/huge_memory.c"
          ],
          "defaultStatus": "unaffected"
        },
        {
          "repo": "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git",
          "vendor": "Linux",
          "product": "Linux",
          "versions": [
            {
              "status": "affected",
              "version": "5.16"
            },
            {
              "status": "unaffected",
              "version": "0",
              "lessThan": "5.16",
              "versionType": "semver"
            },
            {
              "status": "unaffected",
              "version": "5.19.6",
              "versionType": "semver",
              "lessThanOrEqual": "5.19.*"
            },
            {
              "status": "unaffected",
              "version": "6.0",
              "versionType": "original_commit_for_fix",
              "lessThanOrEqual": "*"
            }
          ],
          "programFiles": [
            "include/linux/mm.h",
            "mm/gup.c",
            "mm/huge_memory.c"
          ],
          "defaultStatus": "affected"
        }
      ]
    }
  ],
  "published": "2025-06-18T11:15:29.470",
  "references": [
    {
      "url": "https://git.kernel.org/stable/c/5535be3099717646781ce1540cf725965d680e7b",
      "tags": [
        "Patch"
      ],
      "source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67"
    },
    {
      "url": "https://git.kernel.org/stable/c/9def52eb10baab3b700858003d462fcf17d62873",
      "tags": [
        "Patch"
      ],
      "source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67"
    }
  ],
  "vulnStatus": "Modified",
  "weaknesses": [
    {
      "type": "Primary",
      "source": "nvd@nist.gov",
      "description": [
        {
          "lang": "en",
          "value": "CWE-362"
        }
      ]
    }
  ],
  "descriptions": [
    {
      "lang": "en",
      "value": "In the Linux kernel, the following vulnerability has been resolved:\n\nmm/gup: fix FOLL_FORCE COW security issue and remove FOLL_COW\n\nEver since the Dirty COW (CVE-2016-5195) security issue happened, we know\nthat FOLL_FORCE can be possibly dangerous, especially if there are races\nthat can be exploited by user space.\n\nRight now, it would be sufficient to have some code that sets a PTE of a\nR/O-mapped shared page dirty, in order for it to erroneously become\nwritable by FOLL_FORCE.  The implications of setting a write-protected PTE\ndirty might not be immediately obvious to everyone.\n\nAnd in fact ever since commit 9ae0f87d009c (\"mm/shmem: unconditionally set\npte dirty in mfill_atomic_install_pte\"), we can use UFFDIO_CONTINUE to map\na shmem page R/O while marking the pte dirty.  This can be used by\nunprivileged user space to modify tmpfs/shmem file content even if the\nuser does not have write permissions to the file, and to bypass memfd\nwrite sealing -- Dirty COW restricted to tmpfs/shmem (CVE-2022-2590).\n\nTo fix such security issues for good, the insight is that we really only\nneed that fancy retry logic (FOLL_COW) for COW mappings that are not\nwritable (!VM_WRITE).  And in a COW mapping, we really only broke COW if\nwe have an exclusive anonymous page mapped.  If we have something else\nmapped, or the mapped anonymous page might be shared (!PageAnonExclusive),\nwe have to trigger a write fault to break COW.  If we don't find an\nexclusive anonymous page when we retry, we have to trigger COW breaking\nonce again because something intervened.\n\nLet's move away from this mandatory-retry + dirty handling and rely on our\nPageAnonExclusive() flag for making a similar decision, to use the same\nCOW logic as in other kernel parts here as well.  In case we stumble over\na PTE in a COW mapping that does not map an exclusive anonymous page, COW\nwas not properly broken and we have to trigger a fake write-fault to break\nCOW.\n\nJust like we do in can_change_pte_writable() added via commit 64fe24a3e05e\n(\"mm/mprotect: try avoiding write faults for exclusive anonymous pages\nwhen changing protection\") and commit 76aefad628aa (\"mm/mprotect: fix\nsoft-dirty check in can_change_pte_writable()\"), take care of softdirty\nand uffd-wp manually.\n\nFor example, a write() via /proc/self/mem to a uffd-wp-protected range has\nto fail instead of silently granting write access and bypassing the\nuserspace fault handler.  Note that FOLL_FORCE is not only used for debug\naccess, but also triggered by applications without debug intentions, for\nexample, when pinning pages via RDMA.\n\nThis fixes CVE-2022-2590. Note that only x86_64 and aarch64 are\naffected, because only those support CONFIG_HAVE_ARCH_USERFAULTFD_MINOR.\n\nFortunately, FOLL_COW is no longer required to handle FOLL_FORCE. So\nlet's just get rid of it.\n\nThanks to Nadav Amit for pointing out that the pte_dirty() check in\nFOLL_FORCE code is problematic and might be exploitable.\n\nNote 1: We don't check for the PTE being dirty because it doesn't matter\n\tfor making a \"was COWed\" decision anymore, and whoever modifies the\n\tpage has to set the page dirty either way.\n\nNote 2: Kernels before extended uffd-wp support and before\n\tPageAnonExclusive (< 5.19) can simply revert the problematic\n\tcommit instead and be safe regarding UFFDIO_CONTINUE. A backport to\n\tv5.19 requires minor adjustments due to lack of\n\tvma_soft_dirty_enabled()."
    },
    {
      "lang": "es",
      "value": "En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: mm/gup: corregir el problema de seguridad de FOLL_FORCE COW y eliminar FOLL_COW Desde que ocurrió el problema de seguridad Dirty COW (CVE-2016-5195), sabemos que FOLL_FORCE puede ser posiblemente peligroso, especialmente si hay ejecuciones que pueden ser explotadas por el espacio de usuario. En este momento, sería suficiente tener algún código que establezca un PTE de una página compartida asignada a R/O sucia, para que FOLL_FORCE pueda escribir en ella por error. Las implicaciones de establecer una PTE protegida contra escritura sucia podrían no ser inmediatamente obvias para todos. Y de hecho, desde el commit 9ae0f87d009c (\"mm/shmem: establecer un pte sucio incondicionalmente en mfill_atomic_install_pte\"), podemos usar UFFDIO_CONTINUE para asignar una página shmem R/O mientras se marca el pte sucio. Esto puede ser usado por usuarios sin privilegios para modificar el contenido de archivos tmpfs/shmem incluso si no tienen permisos de escritura, y para evitar el sellado de escritura de memfd (COW sucio restringido a tmpfs/shmem [CVE-2022-2590]). Para solucionar definitivamente estos problemas de seguridad, la clave es que solo necesitamos esa lógica de reintento sofisticada (FOLL_COW) para las asignaciones de COW que no permiten escritura (!VM_WRITE). En una asignación de COW, solo se interrumpe si se asigna una página anónima exclusiva. Si se asigna otra cosa, o si la página anónima asignada puede ser compartida (!PageAnonExclusive), se debe generar un fallo de escritura para interrumpir COW. Si no se encuentra una página anónima exclusiva al reintentar, se debe activar la interrupción de COW de nuevo porque algo intervino. Dejemos de lado este manejo de reintentos obligatorios y errores de escritura y utilicemos nuestra bandera PageAnonExclusive() para tomar una decisión similar y usar la misma lógica de COW que en otras partes del kernel. Si encontramos una PTE en una asignación de COW que no asigne una página anónima exclusiva, COW no se rompió correctamente y debemos generar un falso fallo de escritura para romperlo. Al igual que en can_change_pte_writable(), añadido mediante el commit 64fe24a3e05e (\"mm/mprotect: intentar evitar errores de escritura en páginas anónimas exclusivas al cambiar la protección\") y el commit 76aefad628aa (\"mm/mprotect: corregir la comprobación de errores de escritura en can_change_pte_writable()\"), nos encargamos de los errores de escritura y uffd-wp manualmente. Por ejemplo, una escritura (write()) mediante /proc/self/mem a un rango protegido por uffd-wp debe fallar en lugar de conceder acceso de escritura silenciosamente y omitir el controlador de errores del espacio de usuario. Tenga en cuenta que FOLL_FORCE no solo se usa para el acceso de depuración, sino que también lo activan aplicaciones sin intenciones de depuración, por ejemplo, al anclar páginas mediante RDMA. Esto corrige CVE-2022-2590. Tenga en cuenta que solo x86_64 y aarch64 se ven afectados, ya que solo estos admiten CONFIG_HAVE_ARCH_USERFAULTFD_MINOR. Afortunadamente, FOLL_COW ya no es necesario para gestionar FOLL_FORCE. Así que simplemente lo eliminaremos. Gracias a Nadav Amit por señalar que la comprobación pte_dirty() en el código de FOLL_FORCE es problemática y podría ser explotable. Nota 1: No comprobamos si la PTE está sucia porque ya no es relevante para tomar la decisión de \"fue COWed\", y quien modifique la página debe configurarla como sucia de todos modos. Nota 2: Los kernels anteriores a la compatibilidad extendida con uffd-wp y a PageAnonExclusive (&lt; 5.19) pueden simplemente revertir el commit problemática y estar seguros con respecto a UFFDIO_CONTINUE. Una adaptación a la versión 5.19 requiere ajustes menores debido a la falta de vma_soft_dirty_enabled()."
    }
  ],
  "lastModified": "2026-08-04T10:18:03.123",
  "configurations": [
    {
      "nodes": [
        {
          "negate": false,
          "cpeMatch": [
            {
              "criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
              "vulnerable": true,
              "matchCriteriaId": "89E99903-E16D-475D-954B-2BAC46C98262",
              "versionEndExcluding": "5.19.6",
              "versionStartIncluding": "5.16"
            },
            {
              "criteria": "cpe:2.3:o:linux:linux_kernel:6.0:rc1:*:*:*:*:*:*",
              "vulnerable": true,
              "matchCriteriaId": "E8BD11A3-8643-49B6-BADE-5029A0117325"
            },
            {
              "criteria": "cpe:2.3:o:linux:linux_kernel:6.0:rc2:*:*:*:*:*:*",
              "vulnerable": true,
              "matchCriteriaId": "5F0AD220-F6A9-4012-8636-155F1B841FAD"
            }
          ],
          "operator": "OR"
        }
      ]
    }
  ],
  "sourceIdentifier": "416baaa9-dc9f-4396-8d5f-8c081fb06d67"
}