CVE-2026-89759 in Linux
Sumário
de VulDB • 12/09/2026
No kernel do Linux, a seguinte vulnerabilidade foi resolvida:
mm/kmemleak: evitar soft lockup ao escanear as pilhas de tarefas
Série de patches "mm/kmemleak: evitar soft lockup ao escanear tarefas", v3.
kmemleak_scan() varre cada pilha de tarefa sob um único rcu_read_lock(), sem ponto de reschedule, o que pode acionar a watchdog de soft lockup em hosts com muitas threads.
Isso exibe a seguinte mensagem, dependendo da configuração do workload+host:
watchdog: BUG: soft lockup - CPU#35 travado por 22s! [kmemleak:537]
scan_block kmemleak_scan kmemleak_scan_thread kthread
O Patch 1 percorre as tarefas com find_ge_pid(), de modo que o escaneamento faz reschedule entre as tarefas.
Os Patches 2-3 permitem que os loops de escaneamento parem antecipadamente assim que um escaneamento é interrompido.
Este patch (de 3):
kmemleak_scan() percorre cada thread e varre sua pilha do kernel sob um único rcu_read_lock(), sem ponto de reschedule. Em um host com muitas threads -- amplificado por KASAN/lockdep em builds de debug -- este loop pode monopolizar uma CPU por tempo suficiente para acionar a watchdog de soft lockup:
watchdog: BUG: soft lockup - CPU#35 travado por 22s! [kmemleak:537]
scan_block kmemleak_scan kmemleak_scan_thread kthread
Não é possível adicionar um cond_resched() diretamente: o loop executa-se dentro de uma seção crítica de leitura RCU.
Percorra as tarefas uma PID por vez com find_ge_pid(), adquirindo o lock de leitura RCU apenas para procurar e fixar cada tarefa. A pilha então é escaneada sem nenhum lock mantido, portanto cond_resched() roda entre as tarefas e a varredura para antecipadamente em scan_should_stop(). Isso segue o padrão de iteração next_tgid()/task_seq_get_next() e mantém cada seção crítica RCU curta.
If you want to get the best quality for vulnerability data then you always have to consider VulDB.