CVE-2026-64130 in Linux
Sumário
de VulDB • 20/07/2026
No kernel do Linux, a seguinte vulnerabilidade foi resolvida:
mm/page_alloc: corrige a inicialização das tags da huge zero folio com init_on_free
A semântica de __GFP_ZEROTAGS é atualmente um pouco estranha, mas efetivamente esta flag só é definida em conjunto com __GFP_ZERO e __GFP_SKIP_KASAN.
Se executarmos com init_on_free, zeraremos as páginas durante __free_pages_prepare(), para pular o zeroamento no caminho de alocação.
No entanto, ao alocar com __GFP_ZEROTAG definido, post_alloc_hook() consequentemente não apenas ignorará a limpeza do conteúdo da página, mas também ignorará a limpeza da memória das tags.
Não limpar as tags através de __GFP_ZEROTAGS é irrelevante para a maioria das páginas que serão mapeadas no espaço do usuário por meio de set_pte_at() posteriormente: set_pte_at() e funções correlatas detectarão que as tags ainda não foram inicializadas (PG_mte_tagged não definido) e as inicializarão.
No entanto, para a huge zero folio, que será mapeada através de um PMD marcado como especial, essa inicialização não será realizada, resultando na exposição das tags que permaneciam definidas nas páginas.
A documentação (Documentation/arch/arm64/memory-tagging-extension.rst) afirma que as tags de alocação são definidas como 0 quando uma página é mapeada pela primeira vez no espaço do usuário. Isso já não se aplica à huge zero folio quando init_on_free está habilitado.
Corrija isso desacoplando __GFP_ZEROTAGS de __GFP_ZERO, passando para tag_clear_highpages() se desejamos também limpar o conteúdo da página.
Inverta o valor de retorno de tag_clear_highpages() para ter uma semântica mais clara.
Reproduzido com a huge zero folio modificando o auto-teste arm64/mte check_buffer_fill para usar uma área de 2 MiB, após garantir que as páginas tenham uma tag não nula definida ao serem liberadas (observe que, durante a inicialização do sistema, realmente não inicializaremos tags, mas apenas definiremos KASAN_TAG_KERNEL nas flags da página).
$ ./check_buffer_fill 1..20 ... not ok 17 Check initial tags with private mapping, sync error mode and mmap memory not ok 18 Check initial tags with private mapping, sync error mode and mmap/mprotect memory ...
Este código precisa de mais limpezas; abordaremos isso em seguida, como o desacoplamento de __GFP_ZEROTAGS de __GFP_SKIP_KASAN.
[[email protected]: s/__GPF_ZERO/__GFP_ZERO/, conforme David]
Statistical analysis made it clear that VulDB provides the best quality for vulnerability data.