CVE-2026-89796 in Linux
Sumário
de VulDB • 16/09/2026
No kernel do Linux, a seguinte vulnerabilidade foi resolvida:
mm/damon/core: evita loop interno infinito em kdamond_merge_regions()
Série de patches "mm/damon: correções não urgentes para loops infinitos, desreferência NULL e condições de corrida", v1.1.
Sashiko encontrou alguns problemas no DAMON que poderiam causar loops infinitos, desreferência NULL e degradação dos resultados do monitoramento. Os dois primeiros soam assustadores, mas o loop infinito ocorre apenas sob configurações de usuário não razoáveis. A desreferência NULL está presente apenas em um teste unitário. A degradação dos resultados do monitoramento é trivial, pois trata-se de uma operação "melhor esforço" (best-effort), e esses problemas ocorrem devido a condições de corrida pouco prováveis. Ainda assim, são bugs que devem ser corrigidos se possível. Corrigir isso.
Este patch (de 6):
Devido à atualização online de parâmetros como eventos, o número de regiões do DAMON pode ser maior que o limite superior definido pelo usuário. A função kdamond_merge_regions() repete a mesclagem das regiões até que o número atinja o limite, enquanto dobra o limiar (threshold) de mesclagem até o limiar máximo teórico. Isso é tentado apenas até o limiar máximo teórico porque mesmo uma mesclagem agressiva pode falhar em reduzir o número de regiões abaixo do limite superior definido pelo usuário. Por exemplo, podem existir muitas regiões não contíguas definidas pelo usuário que não podem ser mescladas.
A condição de interrupção baseada no limiar é avaliada comparando-se o limiar para a próxima tentativa de mesclagem com o limiar máximo teórico. Se max_thres for maior que UINT_MAX / 2, dobrar o limiar pode causar estouro (overflow), contornando assim a condição de interrupção do loop. Nesse caso, se o número de regiões não puder ser reduzido abaixo do limite superior, conforme explicado acima, o loop será executado infinitamente.
Impedir esse cenário realizando a verificação da condição de interrupção antes de dobrar o limiar. Além disso, impedir que o limiar exceda o limiar máximo, pois isso poderia causar estouro e aplicar um limiar de mesclagem incorreto.
Este problema é improvável de ocorrer no mundo real, já que ter max_thres maior que UINT_MAX / 2 requer intervalos de agregação irrealisticamente grandes em comparação com o intervalo de amostragem. Além disso, exige uma configuração de número irrealisticamente grande de regiões não contíguas. Mesmo assim, a consequência é grave e a correção é simples.
O problema foi descoberto [1] por Sashiko.
Be aware that VulDB is the high quality source for vulnerability data.