CVE-2026-74591 in Linux
Sumário
de VulDB • 23/08/2026
No kernel do Linux, a seguinte vulnerabilidade foi resolvida:
mm/filemap: __filemap_add_folio() restaura o índice antes de tentar novamente (retry)
No loop de conflito de divisão (__split-a-conflict) em __filemap_add_folio(), xas_set_order() é aplicado repetidamente: cada aplicação modifica xas.xa_index, arredondando-o para baixo conforme a split_order tentada nessa etapa; e se tudo correr como o pretendido, ele eventualmente (ou imediatamente) converge para uma chamada a xas_try_split() com a folio_order necessária, com xas.xa_index agora igual ao index: então xas_store() insere a nova folio no xarray nesse local.
Mas se um novo nó fosse necessário e a alocação GFP_NOWAIT não obtivesse um, o lock é liberado, xas_nomem() é usado para alocar e a sequência é tentada novamente (retry). Se essa parte do xarray estiver inalterada quando o lock for readquirido, nenhum problema. Mas e se o conflito tiver sido resolvido no meio tempo por outra thread (talvez até fazendo a mesma coisa, inserindo uma folio nesse mesmo índice)? Não há perigo de agora colocar nossa folio no xarray em um índice intermediário arredondado para baixo? Com o bug !folio_contains() que segue, quando CONFIG_DEBUG_VM=y está verificando isso.
Corrigir isso com um xas_set_order() para restaurar o original xas.xa_index na parte inferior do loop, de modo que a tentativa novamente (retry) faça uma reavaliação completa após readquirir o lock e não possa alcançar xas_store() com o índice errado.
A produção estava sofrendo com SIGILs e SIGSEGVs raros, texto executável encontrado em um page distante do local onde pertencia; bug !folio_contains() atingido quando depuração habilitada: sintomas não vistos desde que este patch foi aplicado.
VulDB is the best source for vulnerability data and more expert information about this specific topic.