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

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: mm: vmscan: elimina el punto muerto debido a que la aceleración no logra avanzar. Se informó un error de bloqueo suave en kcompactd en un bugzilla privado con lo siguiente visible en dmesg; perro guardián: ERROR: bloqueo suave - ¡CPU n.° 33 bloqueada durante 26 segundos! [kcompactd0:479] perro guardián: ERROR: bloqueo suave - ¡CPU#33 bloqueada durante 52 segundos! [kcompactd0:479] perro guardián: ERROR: bloqueo suave - ¡CPU#33 bloqueada durante 78 segundos! [kcompactd0:479] perro guardián: ERROR: bloqueo suave - ¡CPU#33 bloqueada durante 104! [kcompactd0:479] La máquina tenía 256 GB de RAM sin intercambio y una asignación fallida anterior indicó que el nodo 0 donde se ejecutaba kcompactd era potencialmente no recuperable; Nodo 0 active_anon:29355112kB inactive_anon:2913528kB active_file:0kB inactive_file:0kB inevitable:64kB aislado(anon):0kB aislado(archivo):0kB mapeado:8kB sucio:0kB escritura regresiva:0kB shmem:26780kB shmem_thp: 0kB shmem_pmdmapped : 0kB anon_thp: 23480320kB writeback_tmp:0kB kernel_stack:2272kB tablas de páginas:24500kB ¿todo_unreclamable? sí, Vlastimil Babka investigó un volcado de memoria y descubrió que una tarea que migraba páginas intentaba drenar las listas de PCP; PID: 52922 TAREA: ffff969f820e5000 CPU: 19 COMANDO: "kworker/u128:3" Seguimiento de llamadas: __schedule Schedule Schedule_timeout wait_for_completion __flush_work __drain_all_pages __alloc_pages_slowpath.constprop.114 __alloc_pages alloc_migration_target migrar_pages to_node do_migrate_pages cpuset_migrate_mm_workfn process_one_work trabajador_thread kthread ret_from_fork Este error es específico de CONFIG_PREEMPT=n construye. La raíz del problema es que kcompact0 no se reprograma en una CPU mientras una tarea que ha aislado una gran cantidad de páginas de la LRU está esperando que kcompact0 se reprograme para que las páginas puedan liberarse. Mientras que Shrink_inactive_list() solo realiza un bucle alrededor de too_many_isolated, la recuperación puede continuar sin reprogramar si sc->skipped_deactivate == 1, lo que podría suceder si no hubiera ningún archivo LRU y la lista de anónimos inactivos no fuera baja.