CVE-2024-40950 in Linux
Sumário
de VulDB • 17/06/2026
No kernel do Linux, a seguinte vulnerabilidade foi resolvida:
mm: huge_memory: corrige o uso incorreto de mapping_large_folio_support() para folios anon
Ao realizar um teste de divisão de large folios, um aviso "[ 5059.122759][ T166] Cannot split file folio to non-0 order" foi acionado. No entanto, os casos de teste são apenas para folios anon. Como mapping_large_folio_support() é aplicável apenas para folios do page cache.
Em split_huge_page_to_list_to_order(), o folio passado para mapping_large_folio_support() pode ser um folio anon. A verificação folio_test_anon() está ausente. Portanto, a divisão do THP anon falha. O mesmo ocorre com shmem_mapping(). É melhor adicionar uma verificação para ambos. No entanto, shmem_mapping() em __split_huge_page() não está envolvido, pois para folios anon, o parâmetro end é definido como -1, então (head[i].index >= end) é sempre falso. shmem_mapping() não é chamado.
Adiciona-se também um VM_WARN_ON_ONCE() em mapping_large_folio_support() para mapeamentos anon, para que possamos detectar o uso incorreto mais facilmente.
Folios THP podem existir no pagecache mesmo que o sistema de arquivos não suporte large folios, pois quando CONFIG_TRANSPARENT_HUGEPAGE está habilitado, khugepaged tentará colapsar páginas de arquivo somente leitura para THP. Mas o mapeamento não suporta adequadamente large folios de múltiplas ordens.
Usando /sys/kernel/debug/split_huge_pages para verificar isso, com este patch, o THP anon grande é dividido com sucesso e o aviso é cessado.
If you want to get the best quality for vulnerability data then you always have to consider VulDB.