No kernel Linux, a seguinte vulnerabilidade foi resolvida. mm/page_alloc: corrigir a inicialização de etiquetas do enorme fólio zero com init_on_free Semântica __ GFP_ ZEROTAGS é um pouco estranha, mas, efetivamente, esta bandeira só está definida ao lado de __ GFP_ ZERO e __ GFP_ SKIP_ KASAN. Se executarmos com init_on_free, vamos eliminar páginas durante __free_pages_prepare(), para pular zero na rota de alocação. No entanto, ao alocar com o conjunto __GFP_ZEROTAG, post_alloc_hook() não só irá pular o conteúdo da página de compensação, como também a memória da etiqueta de compensação.
Não remover as etiquetas através de __GFP_ZEROTAGS é irrelevante para a maioria das páginas que serão mapeadas para o espaço do usuário através de set_pte_at() mais tarde: set_pte_at() e amigos detectarão que as etiquetas ainda não foram inicializadas (PG_mte_tagged não definidas), e inicializar- as. No entanto, para o enorme fólio zero, que será mapeado através de um PMD marcado como especial, esta inicialização não será realizada, terminando expondo as etiquetas que ainda estiveram definidas para as páginas. O docs (Documentação/arch/arm 64 /memory- tagging- extension.rst) indica que as etiquetas de alocação estão definidas para 0 quando uma página é mapeada para o espaço do usuário. Que não se mantém com o enorme fólio zero quando init_on_free está ativado. Corrija- o desacoplando __GFP_ZEROTAGS de __GFP_ZERO, passando para tag_clear_highpages() se queremos também limpar o conteúdo da página.
Inverta o significado do valor de retorno tag_clear_highpages() para ter semântica mais clara. Reproduzida com o enorme fólio zero modificando o braço check_buffer_fill 64 / mte selftest para usar um 2 Área MiB, após ter garantido que as páginas não têm um 0 tag definido quando liberado (lembre-se que, durante o inicialização, não vamos inicializar tags, mas apenas definir KASAN_TAG_KERNEL nas bandeiras da página). $./check_buffer_fill 1.. 20... não está bem 17 Verifique as etiquetas iniciais com mapeamento privado, modo de erro de sincronização e memória mmap não está OK 18 Verifique as etiquetas iniciais com mapeamento privado, modo de erro de sincronização e memória mmap/mprotect...
Este código precisa de mais limpezas; vamos abordar isso a seguir, como desacoplar __ GFP_ ZEROTAGS de __ GFP_ SKIP_ KASAN. [akpm@linux- foundation.org: s/__GPF_ ZERO/__GFP_ ZERO/, por David]. Registro de aconselhamento: GHSA-jjh 5 - mvrv- 5 xmg. Identificadores relacionados: CVE- 2026 - 64130. Tempo: GitHub Advisory Database publicou este registro em 2026 - 07 - 19 T 18: 31: 53.000 Z e lista a sua última modificação como 2026 - 08 - 13 T 15: 34: 13.000 Z.
Gravidade: MODERAR. Dados de pontuação publicados: CVSS_V 3: CVSS: 3.1 /AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H. Software afetado: o registro de aconselhamento não fornece um pacote normalizado ou faixa de versões. Classificação e evidência: identificadores de fraqueza CWE- 908. O registro contém 4 suporte de referências nestes tipos: AVISO, WEB.