Vulnerabilidad en kernel de Linux (CVE-2024-38613)

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: m68k: corrige la ejecución de bloqueo de giro en la creación de subprocesos del kernel. El cambio de contexto se encarga de retener el propietario del bloqueo correcto durante el cambio de las tareas 'anteriores' a las 'siguientes'. Esto depende de que las interrupciones permanezcan deshabilitadas durante toda la duración del cambio. Esta condición está garantizada para la creación normal de procesos y el cambio de contexto entre procesos que ya se están ejecutando, porque tanto 'anterior' como 'siguiente' ya tienen las interrupciones deshabilitadas en sus copias guardadas del registro de estado. La situación es diferente para los subprocesos del kernel recién creados. El registro de estado se establece en PS_S en copy_thread(), lo que deja la IPL en 0. Al restaurar el registro de estado del 'siguiente' subproceso en switch_to() también conocido como resume(), las interrupciones se habilitan prematuramente. resume() luego regresa a través de ret_from_kernel_thread() y Schedule_tail() donde se libera el bloqueo de la cola de ejecución (consulte Finish_task_switch() y Finish_lock_switch()). Una interrupción del temporizador que llama a Scheduler_tick() antes de que se libere el bloqueo en Finish_task_switch() encontrará el bloqueo ya tomado, con la tarea actual como propietario del bloqueo. Esto provoca una advertencia de recursividad de spinlock según lo informado por Guenter Roeck. Hasta donde puedo determinar, esta ejecución se abrió en el commit 533e6903bea0 ("m68k: split ret_from_fork(), simplifica kernel_thread()") pero no he realizado un estudio detallado de la historia del kernel, por lo que es posible que sea anterior a esa confirmación. Las interrupciones no se pueden deshabilitar en la copia del registro de estado guardado para los subprocesos del kernel (init se quejará de las interrupciones deshabilitadas cuando finalmente inicie el espacio de usuario). Deshabilite las interrupciones temporalmente al cambiar los conjuntos de registros de tareas en resume(). Tenga en cuenta que un simple oriw 0x700,%sr después de restaurar sr no es suficiente aquí; esto deja suficiente ejecución para que aún se observe la advertencia de 'recursión de spinlock'. Probado en ARAnyM y qemu (emulación Quadra 800).