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

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: x86/mce: usar is_copy_from_user() para determinar el contexto de copia del usuario. Serie de parches "mm/hwpoison: Corregir regresiones en la gestión de fallos de memoria", v4. ## 1. ¿Qué intento hacer?: Este conjunto de parches resuelve dos regresiones críticas relacionadas con la gestión de fallos de memoria que han aparecido en el kernel original desde la versión 5.17, en comparación con la 5.10 LTS. - caso de copyin: se encontró un error en la página de usuario mientras el kernel copiaba desde el espacio de usuario. - caso de instr: se encontró un error al obtener instrucciones en el espacio de usuario. ## 2. ¿Cuál es el resultado esperado y por qué? - Para el caso de copyin: el kernel puede recuperarse del error encontrado donde el kernel ejecuta get_user() o copy_from_user() si en esos lugares se obtiene un error y el kernel devuelve -EFAULT al proceso en lugar de bloquearse. Más específicamente, el controlador de MCE comprueba el tipo de controlador de corrección para decidir si se puede recuperar un #MC en el kernel. Cuando se encuentra EX_TYPE_UACCESS, el PC salta al código de recuperación especificado en _ASM_EXTABLE_FAULT() y devuelve un -EFAULT al espacio de usuario. - En el caso de instr: Si se encuentra un error durante la obtención de instrucciones en el espacio de usuario, es posible una recuperación completa. El proceso de usuario toma #PF, Linux asigna una nueva página y la completa leyendo del almacenamiento. ## 3. Qué sucede realmente y por qué - En el caso de copyin: Pánico del kernel desde la v5.17. El commit 4c132d1d844a ("x86/futex: Eliminar el uso de .fixup") introdujo un nuevo tipo de corrección extable, EX_TYPE_EFAULT_REG, y parches posteriores actualizaron el tipo de corrección extable para operaciones de copia desde el usuario, cambiándolo de EX_TYPE_UACCESS a EX_TYPE_EFAULT_REG. Esto interrumpe la gestión previo de EX_TYPE_UACCESS cuando se encuentra error en get_user() o copy_from_user(). - Para el caso instr: el proceso del usuario es eliminado por una señal SIGBUS debido a la ejecución #CMCI y #MCE Cuando se consume un error de memoria sin corregir, hay una ejecución entre el CMCI del controlador de memoria que informa un error sin corregir con una firma UCNA y el informe del núcleo y la comprobación de la máquina con firma SRAR cuando los datos están a punto de consumirse. ### Antecedentes: por qué los errores *UN*corregidos están vinculados a *C*MCI en la plataforma Intel [1] Antes de Icelake, los controladores de memoria informaban de eventos de depuración de patrullaje que detectaban un error sin corregir no visto previamente en la memoria mediante la señalización de una comprobación de la máquina de difusión con una firma SRAO (Acción recuperable de software opcional) en el banco de comprobación de la máquina. Esto era excesivo porque no es un problema urgente que ningún núcleo esté a punto de consumir esos datos erróneos. También se ha descubierto que varias UCE SRAO pueden causar interrupciones MCE anidadas y, finalmente, convertirse en una IERR. Por lo tanto, Intel degrada la firma del banco de verificación de la máquina de la limpieza de patrullaje de SRAO a UCNA (sin corregir, no se requiere acción) y la señal cambia a #CMCI. Para aumentar la confusión, Linux realiza una acción (en uc_decode_notifier()) para intentar desconectar la página a pesar del nombre de la firma UC*NA*. ### Antecedentes: ¿por qué #CMCI y #MCE compiten cuando el veneno consume datos en la plataforma Intel? [1] Tras decidir que CMCI/UCNA es la mejor acción para los errores de limpieza de patrullaje, el controlador de memoria también la utiliza para las lecturas. Sin embargo, el controlador de memoria se ejecuta de forma asíncrona desde el núcleo y no puede distinguir entre una lectura "real" y una lectura especulativa. Por lo tanto, ejecutará CMCI/UCNA si se encuentra un error en cualquier lectura. Por lo tanto: 1) El núcleo es inteligente y cree que ----truncada---