Vulnerabilidad en kernel de Linux (CVE-2025-22034)

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: mm/gup: rechazo de FOLL_SPLIT_PMD con VMAs hugetlb. Serie de parches "mm: correcciones para entradas exclusivas de dispositivo (hmm)", v2. Al hablar con Willy sobre la llamada a PageTail() en make_device_exclusive_range(), descubrí recientemente [1] que la gestión exclusiva de dispositivo no funciona correctamente con THP, lo que provoca que las autopruebas hmm-tests fallen si las THP están habilitadas en el sistema. Al analizar más a fondo, descubrí que hugetlb no está correctamente protegido y me di cuenta de que algo que me había estado molestando durante mucho tiempo (la interacción de las entradas exclusivas de dispositivo con mapcounts) interrumpe por completo la gestión de migración/intercambio/división/hwpoison de estos folios mientras tienen PTE exclusivas de dispositivo. El programa a continuación se puede usar para asignar 1 GiB de páginas y convertirlas en exclusivas de dispositivo en un kernel con CONFIG_TEST_HMM. Una vez que son exclusivos del dispositivo, estos folios no se pueden intercambiar (proc$pid/smaps_rollup siempre indicará 1 GiB RSS sin importar cuánto se fuerce la recuperación de memoria) y cuando se tiene un bloque de memoria en línea en ZONE_MOVABLE, al intentar desconectarlo se repetirá eternamente y se quejará sobre la migración fallida de una página que debería ser movible. # echo offline > /sys/devices/system/memory/memory136/state # echo online_movable > /sys/devices/system/memory/memory136/state # ./hmm-swap & ... wait until everything is device-exclusive # echo offline > /sys/devices/system/memory/memory136/state [ 285.193431][T14882] page: refcount:2 mapcount:0 mapping:0000000000000000 index:0x7f20671f7 pfn:0x442b6a [ 285.196618][T14882] memcg:ffff888179298000 [ 285.198085][T14882] anon flags: 0x5fff0000002091c(referenced|uptodate| dirty|active|owner_2|swapbacked|node=1|zone=3|lastcpupid=0x7ff) [ 285.201734][T14882] raw: ... [ 285.204464][T14882] raw: ... [ 285.207196][T14882] page dumped because: migration failure [ 285.209072][T14882] page_owner tracks the page as allocated [ 285.210915][T14882] page last allocated via order 0, migratetype Movable, gfp_mask 0x140dca(GFP_HIGHUSER_MOVABLE|__GFP_COMP|__GFP_ZERO), id 14926, tgid 14926 (hmm-swap), ts 254506295376, free_ts 227402023774 [ 285.216765][T14882] post_alloc_hook+0x197/0x1b0 [ 285.218874][T14882] get_page_from_freelist+0x76e/0x3280 [ 285.220864][T14882] __alloc_frozen_pages_noprof+0x38e/0x2740 [ 285.223302][T14882] alloc_pages_mpol+0x1fc/0x540 [ 285.225130][T14882] folio_alloc_mpol_noprof+0x36/0x340 [ 285.227222][T14882] vma_alloc_folio_noprof+0xee/0x1a0 [ 285.229074][T14882] __handle_mm_fault+0x2b38/0x56a0 [ 285.230822][T14882] handle_mm_fault+0x368/0x9f0 ... Esta serie corrige todos los problemas que he encontrado hasta ahora. No hay una solución sencilla sin una revisión o limpieza más profunda. Tengo varias correcciones adicionales (algunas enviadas previamente, otras resultantes de la discusión en la v1) que publicaré por separado una vez que esté disponible y pueda con ello. Ojalá pudiéramos usar algunas PTE PROT_NONE presentes especiales en lugar de estas entradas de intercambio falso (no presentes, no ninguna); pero eso solo resulta en el mismo problema que seguimos teniendo (falta de bits de PTE de repuesto), y al observar otras entradas de intercambio falso similares, ese barco ya pasó. Con esta serie, make_device_exclusive() ya no pertenece a mm/rmap.c, pero lo dejaré para otro día. Solo probé esta serie con las autopruebas hmm-tests debido a la falta de hardware, así que agradecería algunas pruebas, especialmente si la interacción entre dos GPU que buscan una entrada de dispositivo exclusivo funciona como se espera. #include #include #include #include #include #include #include #include #include #include #define HMM_DMIRROR_EXCLUSIVE _IOWR('H', 0x05, ---truncado---