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

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: sched/core: Evitar la reprogramación cuando las interrupciones están deshabilitadas David informó una advertencia observada durante la prueba del bucle kexec jump: Interrupciones habilitadas después de irqrouter_resume+0x0/0x50 ADVERTENCIA: CPU: 0 PID: 560 en drivers/base/syscore.c:103 syscore_resume+0x18a/0x220 kernel_kexec+0xf6/0x180 __do_sys_reboot+0x206/0x250 do_syscall_64+0x95/0x180 El seguimiento del indicador de interrupción correspondiente: hardirqs se habilitó por última vez en (15573): [] __up_console_sem+0x7e/0x90 hardirqs se desactivó por última vez en (15580): [] __up_console_sem+0x63/0x90. Esto significa que __up_console_sem() se invocó con las interrupciones habilitadas. Una instrumentación más detallada reveló que, en la sección de interrupción deshabilitada de kexec jump, una de las devoluciones de llamada syscore_suspend() despertó una tarea, lo que activó el indicador NEED_RESCHED. Una devolución de llamada posterior en la ruta de reanudación invocó cond_resched(), que a su vez condujo a la invocación del programador: __cond_resched+0x21/0x60 down_timeout+0x18/0x60 acpi_os_wait_semaphore+0x4c/0x80 acpi_ut_acquire_mutex+0x3d/0x100 acpi_ns_get_node+0x27/0x60 acpi_ns_evaluate+0x1cb/0x2d0 acpi_rs_set_srs_method_data+0x156/0x190 acpi_pci_link_set+0x11c/0x290 irqrouter_resume+0x54/0x60 syscore_resume+0x6a/0x200 kernel_kexec+0x145/0x1c0 __do_sys_reboot+0xeb/0x240 do_syscall_64+0x95/0x180 Este es un problema de larga data, que probablemente se hizo más visible con los cambios recientes de printk. Algo hace una activación de tarea y el programador establece el indicador NEED_RESCHED. cond_resched() lo ve establecido e invoca schedule() desde un contexto completamente falso. El programador habilita interrupciones después del cambio de contexto, lo que causa la advertencia anterior al final. Algunas de las rutas de código en syscore_suspend()/resume() pueden provocar la activación de una activación con exactamente las mismas consecuencias. Puede que no lo hayan hecho todavía, pero como comparten mucho código con las operaciones normales, es solo cuestión de tiempo. El problema solo afecta a los modelos de programación PREEMPT_NONE y PREEMPT_VOLUNTARY. La preempción completa no se ve afectada, ya que cond_resched() está deshabilitado y la comprobación de preempción preemptible() tiene en cuenta la bandera de interrupción deshabilitada. Solucione el problema añadiendo una comprobación correspondiente a cond_resched().