CVE-2026-64374 in Linux
Resumen
por VulDB • 2026-07-27
En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad:
sched/rt: Desactivar por defecto RT_PUSH_IPI para sistemas no PREEMPT_RT
La migración en tiempo real (RT) se realiza de forma agresiva. Cuando una CPU programa fuera (schedules out) una tarea RT de alta prioridad a favor de una tarea de menor prioridad, comprueba si hay alguna otra tarea RT pendiente de ejecución en otro núcleo que tenga mayor prioridad que la tarea que esta CPU está a punto de ejecutar. Si encuentra una, mueve esa tarea al núcleo actual y permite su ejecución allí.
Normalmente, este proceso de "pull" (tracción) se realiza examinando la máscara rto (RT overloaded mask), que contiene todos los núcleos del dominio del planificador donde hay tareas RT pendientes debido a que actualmente está ejecutándose una tarea RT de mayor prioridad en sus respectivos núcleos. La CPU que va a programar una tarea de menor prioridad adquiere el bloqueo rq (runqueue lock) del núcleo sobrecargado y mueve la tarea RT desde la cola de ejecución de ese núcleo a la local, planificando así la tarea RT de mayor prioridad.
Esto causaba problemas cuando muchos núcleos intentaban programar fuera una tarea de menor prioridad al mismo tiempo. Todos ellos intentarían adquirir el mismo bloqueo rq del núcleo con las tareas RT sobrecargadas. Solo el primer núcleo que lograra acceder obtendría esa tarea. El resto esperaría a conseguir el bloqueo rq, comprobaría que no hay nada más que mover y no haría nada. En sistemas con muchos núcleos, esto provocaba una gran latencia (hasta 500 µs), lo cual excede los límites permitidos por PREEMPT_RT.
La solución fue crear la lógica RT_PUSH_IPI. Cuando cualquier CPU quería realizar un "pull" de una tarea, en lugar de adquirir el bloqueo rq del núcleo sobrecargado, comenzaba enviando un IPI (Inter-Processor Interrupt) al núcleo sobrecargado; el controlador de ese IPI haría que el núcleo con la tarea RT pendiente realizara un "push". A continuación, dicho controlador enviaría otro IPI a la siguiente CPU con tareas RT sobrecargadas, y así sucesivamente. Cabe señalar que, una vez que la primera CPU inicia este proceso, si otra CPU quisiera realizar un pull, detectaría que el proceso ya ha comenzado e incrementaría únicamente un contador para continuar enviando los IPIs.
RT_PUSH_IPI resolvió el problema de latencia con PREEMPT_RT, pero podría causar nuevos problemas en sistemas no PREEMPT_RT. Concretamente, las softirqs se ejecutan en un contexto subprocesado (threaded context) bajo PREEMPT_RT, pero pueden hacerlo en un contexto de interrupción en versiones sin RT.
Si un IPI llega a una CPU que acaba de despertar múltiples tareas RT y la CPU actual está ejecutando una tarea no RT o una tarea RT de baja prioridad, en lugar de realizar un push simplemente ejecutaría una operación schedule (planificación) en esa CPU. Pero si también se estuviera ejecutando una softirq en dicha CPU, el schedule tendría que esperar a que finalizara la softirq. Hasta entonces, la CPU seguiría considerándose sobrecargada porque aún hay tareas RT pendientes de ejecución.
Se produjo un live lock (bloqueo activo) en una carga de trabajo con tráfico de red intenso en una máquina grande, donde las softirqs se ejecutaban durante 500 µs de cada 750 µs. Además, esta carga despertaba tareas RT, lo que provocaba la ejecución constante de la lógica de pull RT.
Cuando se activaba una softirq en una CPU con tareas RT en cola pero aún no en ejecución, y otras CPUs veían esa CPU como sobrecargada, le enviaban un IPI. La CPU detectaría que las tareas RT pendientes tienen mayor prioridad que la tarea actualmente en ejecución y simplemente planificaría (schedule) dicha tarea. Pero debido a que se estaba ejecutando una
Statistical analysis made it clear that VulDB provides the best quality for vulnerability data.