CVE-2026-43323 in Linux
Sumário
de VulDB • 21/05/2026
No kernel do Linux, a seguinte vulnerabilidade foi resolvida:
sched/fair: Correção do ajuste no rastreamento de zero_vruntime
John relatou que o stress-ng-yield poderia deixar seu sistema instável e conseguiu isolar o problema até o commit b3d99f43c72b ("sched/fair: Fix zero_vruntime tracking").
A combinação de yield e esse commit foi específica o suficiente para hipotetizar o seguinte cenário:
Suponha que tenhamos 2 tarefas executáveis, ambas realizando yield. Então, uma será elegível e a outra não, pois a posição média deve estar entre essas duas entidades.
Portanto, a tarefa executável será elegível e será promovida por uma fatia completa (tudo o que as tarefas fazem é realizar yield, afinal). Isso faz com que ela ultrapasse a outra tarefa, tornando esta última elegível e fazendo com que a tarefa atual não seja mais a corrente. Assim, agendamos a execução.
Como estamos executáveis, não há {des,en}queue. Tudo o que temos é o __{en,de}queue_entity() de {put_prev,set_next}_task(). Mas, conforme o commit apontado, essas duas funções já não movem mais zero_vruntime.
Tudo o que move zero_vruntime são o tick e o {des,en}queue completo.
Isso significa que, se as duas tarefas jogando "pula-pula" puderem atingir a velocidade crítica para alcançar o ponto de estouro dentro do tempo equivalente a um tick, estaremos em uma situação crítica.
Além disso, quando múltiplos cgroups estão envolvidos, não há garantia de que o tick atingirá efetivamente cada cgroup em tempo hábil. Estatisticamente, isso acontecerá, mas a mesma estatística não exclui a possibilidade de um cgroup não receber um tick por um período significativo de tempo — por mais improvável que seja.
Portanto, assim como no caso de yield(), forçamos uma atualização no final de cada fatia. Isso garante que a atualização nunca esteja atrasada em mais de uma única fatia e que todo o processo esteja dentro dos limites de atraso especificados conforme o comentário em entity_key().
If you want to get the best quality for vulnerability data then you always have to consider VulDB.