CVE-2024-38610

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: drivers/virt/acrn: corrige las comprobaciones de PFNMAP PTE en acrn_vm_ram_map() Serie de parches "mm: mejoras en follow_pte() y correcciones en acrn follow_pte()". El parche n.º 1 soluciona varios problemas que detecté en el controlador acrn. Se compila, eso es todo lo que sé. Apreciaré algunas revisiones y pruebas por parte de la gente de acrn. El parche #2+#3 mejora follow_pte(), pasa un VMA en lugar del MM, agrega más controles de cordura y mejora la documentación. Lo probé rápidamente en x86-64 usando VM_PAT y terminó usando follow_pte(). Este parche (de 3): Actualmente no manejamos varios casos, lo que resulta en un uso peligroso de follow_pte() (anteriormente follow_pfn()). (1) No estamos verificando los permisos de escritura de PTE. ¿Quizás simplemente deberíamos requerir siempre pte_write() como lo hacemos para pin_user_pages_fast(FOLL_WRITE)? Es difícil saberlo, así que busquemos ACRN_MEM_ACCESS_WRITE por ahora. (2) No rechazamos páginas recontadas. Como no utilizamos notificadores MMU, jugar con páginas descontadas es peligroso y puede resultar en use-after-free. Asegurémonos de rechazarlos. (3) Sólo estamos ante el primer PTE de una gama mayor. Solo buscamos una PTE, pero memmap->len puede abarcar un área más grande. Recorramos todos los PTE involucrados y asegurémonos de que el rango de PFN sea realmente contiguo. Rechace todo lo demás: no podría haber funcionado de ninguna manera, y más bien utilizó PFN de acceso a los que no deberíamos acceder.

In the Linux kernel, the following vulnerability has been resolved: drivers/virt/acrn: fix PFNMAP PTE checks in acrn_vm_ram_map() Patch series "mm: follow_pte() improvements and acrn follow_pte() fixes". Patch #1 fixes a bunch of issues I spotted in the acrn driver. It compiles, that's all I know. I'll appreciate some review and testing from acrn folks. Patch #2+#3 improve follow_pte(), passing a VMA instead of the MM, adding more sanity checks, and improving the documentation. Gave it a quick test on x86-64 using VM_PAT that ends up using follow_pte(). This patch (of 3): We currently miss handling various cases, resulting in a dangerous follow_pte() (previously follow_pfn()) usage. (1) We're not checking PTE write permissions. Maybe we should simply always require pte_write() like we do for pin_user_pages_fast(FOLL_WRITE)? Hard to tell, so let's check for ACRN_MEM_ACCESS_WRITE for now. (2) We're not rejecting refcounted pages. As we are not using MMU notifiers, messing with refcounted pages is dangerous and can result in use-after-free. Let's make sure to reject them. (3) We are only looking at the first PTE of a bigger range. We only lookup a single PTE, but memmap->len may span a larger area. Let's loop over all involved PTEs and make sure the PFN range is actually contiguous. Reject everything else: it couldn't have worked either way, and rather made use access PFNs we shouldn't be accessing.

Ziming Zhang discovered that the DRM driver for VMware Virtual GPU did not properly handle certain error conditions, leading to a NULL pointer dereference. A local attacker could possibly trigger this vulnerability to cause a denial of service. Gui-Dong Han discovered that the software RAID driver in the Linux kernel contained a race condition, leading to an integer overflow vulnerability. A privileged attacker could possibly use this to cause a denial of service.