CVE-2022-50014

{"id": "CVE-2022-50014", "cveTags": [], "metrics": {"cvssMetricV31": [{"type": "Primary", "source": "nvd@nist.gov", "cvssData": {"scope": "UNCHANGED", "version": "3.1", "baseScore": 7.0, "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.0}]}, "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": "Analyzed", "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\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 (&lt; 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()."}], "lastModified": "2025-11-14T17:59:51.107", "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"}