Vulnerabilidad en kernel de Linux (CVE-2022-50014)

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 (< 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().