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---

In the Linux kernel, the following vulnerability has been resolved: x86/mce: use is_copy_from_user() to determine copy-from-user context Patch series "mm/hwpoison: Fix regressions in memory failure handling", v4. ## 1. What am I trying to do: This patchset resolves two critical regressions related to memory failure handling that have appeared in the upstream kernel since version 5.17, as compared to 5.10 LTS. - copyin case: poison found in user page while kernel copying from user space - instr case: poison found while instruction fetching in user space ## 2. What is the expected outcome and why - For copyin case: Kernel can recover from poison found where kernel is doing get_user() or copy_from_user() if those places get an error return and the kernel return -EFAULT to the process instead of crashing. More specifily, MCE handler checks the fixup handler type to decide whether an in kernel #MC can be recovered. When EX_TYPE_UACCESS is found, the PC jumps to recovery code specified in _ASM_EXTABLE_FAULT() and return a -EFAULT to user space. - For instr case: If a poison found while instruction fetching in user space, full recovery is possible. User process takes #PF, Linux allocates a new page and fills by reading from storage. ## 3. What actually happens and why - For copyin case: kernel panic since v5.17 Commit 4c132d1d844a ("x86/futex: Remove .fixup usage") introduced a new extable fixup type, EX_TYPE_EFAULT_REG, and later patches updated the extable fixup type for copy-from-user operations, changing it from EX_TYPE_UACCESS to EX_TYPE_EFAULT_REG. It breaks previous EX_TYPE_UACCESS handling when posion found in get_user() or copy_from_user(). - For instr case: user process is killed by a SIGBUS signal due to #CMCI and #MCE race When an uncorrected memory error is consumed there is a race between the CMCI from the memory controller reporting an uncorrected error with a UCNA signature, and the core reporting and SRAR signature machine check when the data is about to be consumed. ### Background: why *UN*corrected errors tied to *C*MCI in Intel platform [1] Prior to Icelake memory controllers reported patrol scrub events that detected a previously unseen uncorrected error in memory by signaling a broadcast machine check with an SRAO (Software Recoverable Action Optional) signature in the machine check bank. This was overkill because it's not an urgent problem that no core is on the verge of consuming that bad data. It's also found that multi SRAO UCE may cause nested MCE interrupts and finally become an IERR. Hence, Intel downgrades the machine check bank signature of patrol scrub from SRAO to UCNA (Uncorrected, No Action required), and signal changed to #CMCI. Just to add to the confusion, Linux does take an action (in uc_decode_notifier()) to try to offline the page despite the UC*NA* signature name. ### Background: why #CMCI and #MCE race when poison is consuming in Intel platform [1] Having decided that CMCI/UCNA is the best action for patrol scrub errors, the memory controller uses it for reads too. But the memory controller is executing asynchronously from the core, and can't tell the difference between a "real" read and a speculative read. So it will do CMCI/UCNA if an error is found in any read. Thus: 1) Core is clever and thinks address A is needed soon, issues a speculative read. 2) Core finds it is going to use address A soon after sending the read request 3) The CMCI from the memory controller is in a race with MCE from the core that will soon try to retire the load from address A. Quite often (because speculation has got better) the CMCI from the memory controller is delivered before the core is committed to the instruction reading address A, so the interrupt is taken, and Linux offlines the page (marking it as poison). ## Why user process is killed for instr case Commit 046545a661af ("mm/hwpoison: fix error page recovered but reported "not ---truncated---