Vulnerabilidad en kernel de Linux (CVE-2023-52490)

En el kernel de Linux, se resolvió la siguiente vulnerabilidad: mm: migrar: se corrigió la asignación de página incorrecta durante la migración de la página Al ejecutar la prueba de estrés, encontramos el siguiente bloqueo del kernel después de unas horas: No se puede manejar la desreferencia del puntero NULL del kernel en virtual dirección 0000000000000000 pc: dentry_name+0xd8/0x224 lr: puntero+0x22c/0x370 sp: ffff800025f134c0 ...... Rastreo de llamadas: dentry_name+0xd8/0x224 puntero+0x22c/0x370 vsnprintf+0x1ec/0x730 vscnprint f+0x2c/0x60 vprintk_store+ 0x70/0x234 vprintk_emit+0xe0/0x24c vprintk_default+0x3c/0x44 vprintk_func+0x84/0x2d0 printk+0x64/0x88 __dump_page+0x52c/0x530 dump_page+0x14/0x20 set_migratetype_isolate+0x110/0x22 4 start_isolate_page_range+0xc4/0x20c offline_pages+0x124/0x474 memoria_block_offline+ 0x44/0xf4 Memory_subsys_offline+0x3c/0x70 device_offline+0xf0/0x120 ...... Después de analizar vmcore, descubrí que este problema se debe a la migración de la página. El escenario es que un hilo está realizando la migración de la página y usaremos el campo ->mapping de la página de destino para guardar el puntero 'anon_vma' entre la desasignación de la página y el movimiento de la página, y ahora la página de destino está bloqueada y el recuento es 1. Actualmente, Hay otro subproceso estresante que realiza una conexión en caliente de la memoria, intentando desconectar la página de destino que se está migrando. Descubre que el refcount de esta página de destino es 1, impidiendo la operación fuera de línea, procediendo así a volcar la página. Sin embargo, page_mapping() de la página de destino puede devolver una asignación de archivos incorrecta para bloquear el sistema en dump_mapping(), ya que la página de destino->mapping solo guarda el puntero 'anon_vma' sin configurar el indicador PAGE_MAPPING_ANON. Hay varias formas de solucionar este problema: (1) Configurar el indicador PAGE_MAPPING_ANON para la página de destino ->mapping al guardar 'anon_vma', pero esto puede confundir a PageAnon() para los usuarios de PFN, ya que la página de destino aún no ha creado asignaciones. (2) Hacer que el bloqueo de página llame a page_mapping() en __dump_page() para evitar bloquear el sistema; sin embargo, todavía hay algunos caminantes PFN que llaman a page_mapping() sin mantener el bloqueo de página, como la compactación. (3) Usar página de destino->campo privado para guardar el puntero 'anon_vma' y el estado de la página de 2 bits, tal como página->mapping registra una página anónima, lo que puede eliminar el impacto de page_mapping() para los caminantes de PFN y también parece una solución simple forma. Así que elijo la opción 3 para solucionar este problema, y esto también puede solucionar otros problemas potenciales para los caminantes PFN, como la compactación.