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

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: mm: zswap: sincronizar correctamente la liberación de recursos durante la desconexión en caliente de la CPU En zswap_compress() y zswap_decompress(), se recupera y se utiliza en todo momento el acomp_ctx por CPU de la CPU actual al comienzo de la operación. Sin embargo, dado que ni la preempción ni la migración están deshabilitadas, es posible que la operación continúe en una CPU diferente. Si se desconecta en caliente la CPU original mientras el acomp_ctx todavía está en uso, nos encontramos con un error de UAF ya que algunos de los recursos adjuntos al acomp_ctx se liberan durante la desconexión en caliente en zswap_cpu_comp_dead() (es decir, acomp_ctx.buffer, acomp_ctx.req o acomp_ctx.acomp). El problema se introdujo en el commit 1ec3b5fe6eec ("mm/zswap: pasar a usar la API crypto_acomp para la aceleración de hardware") cuando se realizó el cambio a la API crypto_acomp. Antes de eso, el crypto_comp por CPU se recuperaba usando get_cpu_ptr() que deshabilita la preempción y se asegura de que la CPU no pueda irse de debajo de nosotros. La preempción no se puede deshabilitar con la API crypto_acomp ya que se necesita un contexto inactivo. Use acomp_ctx.mutex para sincronizar las devoluciones de llamadas hotplug de la CPU que asignan y liberan recursos con rutas de compresión/descompresión. Asegúrese de que acomp_ctx.req sea NULL cuando se liberan los recursos. En las rutas de compresión/descompresión, verifique si acomp_ctx.req es NULL después de adquirir el mutex (lo que significa que la CPU estaba fuera de línea) y vuelva a intentarlo en la nueva CPU. La inicialización de acomp_ctx.mutex se mueve de la devolución de llamada hotplug de la CPU a la inicialización del grupo donde pertenece (donde se asigna el mutex). Además de agregar claridad, esto asegura que la conexión en caliente de la CPU no pueda reinicializar un mutex que ya está bloqueado por compresión/descompresión. Anteriormente se intentó una solución manteniendo pulsada la tecla cpus_read_lock() [1]. Esto habría provocado un posible bloqueo, ya que es posible que el código que ya mantiene el bloqueo caiga en recuperación y entre en zswap (provocando un bloqueo). También se intentó una solución utilizando SRCU para la sincronización, pero Johannes señaló que no se puede utilizarsynchronous_srcu() en los notificadores de conexión en caliente de la CPU [2]. Workarounds que se consideraron/intentaron y que podrían haber funcionado: - Refcounting el acomp_ctx por CPU. Esto implica complejidad en la gestión de la ejecución entre el refcount que cae a cero en zswap_[de]compress() y el refcount que se reinicializa cuando la CPU está en línea. - Deshabilitar la migración antes de obtener el acomp_ctx por CPU [3], pero eso no se recomienda y es un martillo mucho más grande de lo necesario, y podría dar lugar a problemas de rendimiento sutiles. [1]https://lkml.kernel.org/20241219212437.2714151-1-yosryahmed@google.com/ [2]https://lkml.kernel.org/20250107074724.1756696-2-yosryahmed@google.com/ [3]https://lkml.kernel.org/20250107222236.2715883-2-yosryahmed@google.com/ [yosryahmed@google.com: eliminar comentario] Enlace: https://lkml.kernel.org/r/CAJD7tkaxS1wjn+swugt8QCvQ-rVF5RZnjxwPGX17k8x9zSManA@mail.gmail.com