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

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: mm: zswap: corrección del bloqueo de crypto_free_acomp() en zswap_cpu_comp_dead(). Actualmente, zswap_cpu_comp_dead() llama a crypto_free_acomp() mientras mantiene el mutex acomp_ctx por CPU. A continuación, crypto_free_acomp() mantiene scomp_lock (mediante crypto_exit_scomp_ops_async()). Por otro lado, crypto_alloc_acomp_node() mantiene scomp_lock (mediante crypto_scomp_init_tfm()) y luego asigna memoria. Si la asignación resulta en una recuperación, podemos intentar mantener el mutex acomp_ctx por CPU. Las dependencias anteriores pueden causar un bloqueo de ABBA. Por ejemplo, en el siguiente escenario: (1) Tarea A ejecutándose en la CPU n.º 1: crypto_alloc_acomp_node() Retiene scomp_lock Ingresa a recuperación Lee per_cpu_ptr(pool->acomp_ctx, 1) (2) La tarea A se desprograma (3) La CPU n.º 1 se desconecta zswap_cpu_comp_dead(CPU n.º 1) Retiene per_cpu_ptr(pool->acomp_ctx, 1)) Llama a crypto_free_acomp() Espera a scomp_lock (4) Tarea A ejecutándose en la CPU n.º 2: Espera a per_cpu_ptr(pool->acomp_ctx, 1) // Lee en la CPU n.º 1 BLOQUEO INTERMEDIO Dado que no es necesario llamar a crypto_free_acomp() con el mutex acomp_ctx por CPU retenido en zswap_cpu_comp_dead(), muévalo después de que se desbloquee el mutex. También se desplazan las llamadas acomp_request_free() y kfree() para mantener la coherencia y evitar posibles dependencias de bloqueo sutil en el futuro. Con esto, solo se establece el valor NULL de los campos acomp_ctx con el mutex retenido. Esto es similar a cómo zswap_cpu_comp_prepare() solo inicializa los campos acomp_ctx con el mutex retenido, después de realizar todas las asignaciones antes de retener el mutex. Oportunistamente, se desplaza la comprobación de valores NULL en acomp_ctx para que se realice antes de la desreferencia del mutex.