CVE-2022-50014 (GCVE-0-2022-50014)
Vulnerability from cvelistv5
Published
2025-06-18 11:01
Modified
2025-06-18 11:01
Severity ?
Summary
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. 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. 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().
References
Impacted products
Vendor Product Version
Linux Linux Version: 9ae0f87d009ca6c4aab2882641ddfc319727e3db
Version: 9ae0f87d009ca6c4aab2882641ddfc319727e3db
 Create a notification for this product.
Show details on NVD website

To clipboard 

{
  "containers": {
    "cna": {
      "affected": [
        {
          "defaultStatus": "unaffected",
          "product": "Linux",
          "programFiles": [
            "include/linux/mm.h",
            "mm/gup.c",
            "mm/huge_memory.c"
          ],
          "repo": "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git",
          "vendor": "Linux",
          "versions": [
            {
              "lessThan": "9def52eb10baab3b700858003d462fcf17d62873",
              "status": "affected",
              "version": "9ae0f87d009ca6c4aab2882641ddfc319727e3db",
              "versionType": "git"
            },
            {
              "lessThan": "5535be3099717646781ce1540cf725965d680e7b",
              "status": "affected",
              "version": "9ae0f87d009ca6c4aab2882641ddfc319727e3db",
              "versionType": "git"
            }
          ]
        },
        {
          "defaultStatus": "affected",
          "product": "Linux",
          "programFiles": [
            "include/linux/mm.h",
            "mm/gup.c",
            "mm/huge_memory.c"
          ],
          "repo": "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git",
          "vendor": "Linux",
          "versions": [
            {
              "status": "affected",
              "version": "5.16"
            },
            {
              "lessThan": "5.16",
              "status": "unaffected",
              "version": "0",
              "versionType": "semver"
            },
            {
              "lessThanOrEqual": "5.19.*",
              "status": "unaffected",
              "version": "5.19.6",
              "versionType": "semver"
            },
            {
              "lessThanOrEqual": "*",
              "status": "unaffected",
              "version": "6.0",
              "versionType": "original_commit_for_fix"
            }
          ]
        }
      ],
      "cpeApplicability": [
        {
          "nodes": [
            {
              "cpeMatch": [
                {
                  "criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
                  "versionEndExcluding": "5.19.6",
                  "versionStartIncluding": "5.16",
                  "vulnerable": true
                },
                {
                  "criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
                  "versionEndExcluding": "6.0",
                  "versionStartIncluding": "5.16",
                  "vulnerable": true
                }
              ],
              "negate": false,
              "operator": "OR"
            }
          ]
        }
      ],
      "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\u0027t find an\nexclusive anonymous page when we retry, we have to trigger COW breaking\nonce again because something intervened.\n\nLet\u0027s 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\u0027s 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\u0027t check for the PTE being dirty because it doesn\u0027t 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 (\u003c 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()."
        }
      ],
      "providerMetadata": {
        "dateUpdated": "2025-06-18T11:01:18.590Z",
        "orgId": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
        "shortName": "Linux"
      },
      "references": [
        {
          "url": "https://git.kernel.org/stable/c/9def52eb10baab3b700858003d462fcf17d62873"
        },
        {
          "url": "https://git.kernel.org/stable/c/5535be3099717646781ce1540cf725965d680e7b"
        }
      ],
      "title": "mm/gup: fix FOLL_FORCE COW security issue and remove FOLL_COW",
      "x_generator": {
        "engine": "bippy-1.2.0"
      }
    }
  },
  "cveMetadata": {
    "assignerOrgId": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
    "assignerShortName": "Linux",
    "cveId": "CVE-2022-50014",
    "datePublished": "2025-06-18T11:01:18.590Z",
    "dateReserved": "2025-06-18T10:57:27.388Z",
    "dateUpdated": "2025-06-18T11:01:18.590Z",
    "state": "PUBLISHED"
  },
  "dataType": "CVE_RECORD",
  "dataVersion": "5.1",
  "vulnerability-lookup:meta": {
    "nvd": "{\"cve\":{\"id\":\"CVE-2022-50014\",\"sourceIdentifier\":\"416baaa9-dc9f-4396-8d5f-8c081fb06d67\",\"published\":\"2025-06-18T11:15:29.470\",\"lastModified\":\"2025-06-18T13:46:52.973\",\"vulnStatus\":\"Awaiting Analysis\",\"cveTags\":[],\"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\u0027t find an\\nexclusive anonymous page when we retry, we have to trigger COW breaking\\nonce again because something intervened.\\n\\nLet\u0027s 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\u0027s 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\u0027t check for the PTE being dirty because it doesn\u0027t 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 (\u003c 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\u00f3 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\u00eda suficiente tener alg\u00fan c\u00f3digo que establezca un PTE de una p\u00e1gina 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\u00edan 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\u00e1gina 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\u00f3gica de reintento sofisticada (FOLL_COW) para las asignaciones de COW que no permiten escritura (!VM_WRITE). En una asignaci\u00f3n de COW, solo se interrumpe si se asigna una p\u00e1gina an\u00f3nima exclusiva. Si se asigna otra cosa, o si la p\u00e1gina an\u00f3nima asignada puede ser compartida (!PageAnonExclusive), se debe generar un fallo de escritura para interrumpir COW. Si no se encuentra una p\u00e1gina an\u00f3nima exclusiva al reintentar, se debe activar la interrupci\u00f3n 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\u00f3n similar y usar la misma l\u00f3gica de COW que en otras partes del kernel. Si encontramos una PTE en una asignaci\u00f3n de COW que no asigne una p\u00e1gina an\u00f3nima exclusiva, COW no se rompi\u00f3 correctamente y debemos generar un falso fallo de escritura para romperlo. Al igual que en can_change_pte_writable(), a\u00f1adido mediante el commit 64fe24a3e05e (\\\"mm/mprotect: intentar evitar errores de escritura en p\u00e1ginas an\u00f3nimas exclusivas al cambiar la protecci\u00f3n\\\") y el commit 76aefad628aa (\\\"mm/mprotect: corregir la comprobaci\u00f3n 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\u00f3n, sino que tambi\u00e9n lo activan aplicaciones sin intenciones de depuraci\u00f3n, por ejemplo, al anclar p\u00e1ginas 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\u00ed que simplemente lo eliminaremos. Gracias a Nadav Amit por se\u00f1alar que la comprobaci\u00f3n pte_dirty() en el c\u00f3digo de FOLL_FORCE es problem\u00e1tica y podr\u00eda ser explotable. Nota 1: No comprobamos si la PTE est\u00e1 sucia porque ya no es relevante para tomar la decisi\u00f3n de \\\"fue COWed\\\", y quien modifique la p\u00e1gina debe configurarla como sucia de todos modos. Nota 2: Los kernels anteriores a la compatibilidad extendida con uffd-wp y a PageAnonExclusive (\u0026lt; 5.19) pueden simplemente revertir el commit problem\u00e1tica y estar seguros con respecto a UFFDIO_CONTINUE. Una adaptaci\u00f3n a la versi\u00f3n 5.19 requiere ajustes menores debido a la falta de vma_soft_dirty_enabled().\"}],\"metrics\":{},\"references\":[{\"url\":\"https://git.kernel.org/stable/c/5535be3099717646781ce1540cf725965d680e7b\",\"source\":\"416baaa9-dc9f-4396-8d5f-8c081fb06d67\"},{\"url\":\"https://git.kernel.org/stable/c/9def52eb10baab3b700858003d462fcf17d62873\",\"source\":\"416baaa9-dc9f-4396-8d5f-8c081fb06d67\"}]}}"
  }
}


Log in or create an account to share your comment.




Tags
Taxonomy of the tags.




Sightings

Author Source Type Date

Nomenclature

  • Seen: The vulnerability was mentioned, discussed, or seen somewhere by the user.
  • Confirmed: The vulnerability is confirmed from an analyst perspective.
  • Exploited: This vulnerability was exploited and seen by the user reporting the sighting.
  • Patched: This vulnerability was successfully patched by the user reporting the sighting.
  • Not exploited: This vulnerability was not exploited or seen by the user reporting the sighting.
  • Not confirmed: The user expresses doubt about the veracity of the vulnerability.
  • Not patched: This vulnerability was not successfully patched by the user reporting the sighting.