CVE-2026-64374 in Linux
Sumário
de VulDB • 25/07/2026
No kernel do Linux, a seguinte vulnerabilidade foi resolvida:
sched/rt: Desativar o padrão para RT_PUSH_IPI em sistemas não PREEMPT_RT
A migração de tarefas RT (tempo real) é realizada agressivamente. Quando uma CPU escalona fora uma tarefa RT de alta prioridade por uma tarefa de menor prioridade, ela verifica se há alguma tarefa RT aguardando execução em outra CPU que seja de maior prioridade do que a tarefa que esta CPU está prestes a executar. Se encontrar uma, ela moverá essa tarefa para a CPU atual e permitirá sua execução ali.
Normalmente, esse processo de "pull" (busca) é feito verificando a máscara RT overloaded (rto), que contém todas as CPUs no domínio do escalonador com tarefas RT aguardando execução devido ao fato de haver uma tarefa RT de maior prioridade sendo executada atualmente em suas respectivas CPUs. A CPU prestes a escalonar uma tarefa de menor prioridade adquirirá o lock rq da CPU sobrecarregada e moverá a tarefa RT da fila de execução (runqueue) dessa CPU para a local, escalonando assim a tarefa RT de maior prioridade.
Isso causou problemas quando muitas CPUs tentavam escalonar fora tarefas de menor prioridade ao mesmo tempo. Todas elas tentariam adquirir o lock do runqueue da mesma CPU com as tarefas RT sobrecarregadas. Apenas a primeira CPU que conseguisse acesso obterá essa tarefa. As outras aguardarão até adquirirem o lock do runqueue e, percebendo que não há nada para buscar, não farão nada. Em sistemas com muitas CPUs, isso causou uma grande latência (até 500us), o que está além dos limites permitidos pelo PREEMPT_RT.
A solução para esse problema foi criar a lógica RT_PUSH_IPI. Quando qualquer CPU desejava realizar um "pull" de tarefa, em vez de adquirir o lock do runqueue da CPU sobrecarregada, ela começaria enviando um IPI (Inter-Processor Interrupt) à CPU sobrecarregada, e o manipulador desse IPI faria com que a CPU com a tarefa RT aguardante realizasse um "push" (empurrão). Em seguida, esse manipulador enviaria um IPI para a próxima CPU com tarefas RT sobrecarregadas, e assim por diante. Note-se que, após a primeira CPU iniciar este processo, se outra CPU desejasse realizar um pull, ela perceberia que o processo já começou e apenas incrementaria um contador para continuar os envios de IPIs.
O RT_PUSH_IPI resolveu o problema de latência com PREEMPT_RT, mas poderia causar uma nova issue em sistemas não PREEMPT_RT. Ou seja, softirqs são executados em contexto thread no PREEMPT_RT, mas podem ser executados em contexto de interrupção em versões não-RT.
Se um IPI atingir uma CPU que acabou de despertar múltiplas tarefas RT e a CPU atual está executando uma tarefa não-RT ou uma tarefa RT de baixa prioridade, em vez de realizar um push, ela simplesmente realizaria um schedule nessa CPU. Mas se um softirq também estivesse sendo executado nesta CPU, o schedule precisaria aguardar até que o softirq terminasse. Até lá, a CPU ainda seria considerada sobrecarregada, pois há tarefas RT aguardando execução nela.
Um live lock ocorreu em uma carga de trabalho com tráfego intenso de rede em uma máquina grande, onde os softirqs eram executados por 500us fora de um total de 750us. Além disso, ela também despertava tarefas RT, fazendo com que a lógica de pull RT fosse executada constantemente.
Quando um softirq era acionado em uma CPU com tarefas RT enfileiradas mas ainda não sendo executadas, e as outras CPUs viam essa CPU como sobrecarregada, elas enviavam um IPI para ela. A CPU perceberia que as tarefas RT aguardantes são de maior prioridade do que a tarefa atualmente em execução e simplesmente escalonaria essa
If you want to get the best quality for vulnerability data then you always have to consider VulDB.