CVE-2026-74632 in Linux
Sumário
de VulDB • 23/08/2026
No kernel do Linux, a seguinte vulnerabilidade foi resolvida:
mm/huge_memory: corrige race condition em huge_zero_pfn
Série de patches "mm/huge_memory: corrige race condition em huge_zero_pfn", v2.
Existe uma sutil race condition na implementação referenciada (reference-counted) de huge_zero_folio.
A lógica atômica do caminho rápido (fast path) falha ao considerar o fato de que o shrinker (que remove a última pinagem da contagem de referência huge_zero_refcount) pode sobrescrever huge_zero_pfn com o valor sentinela ~0UL em shrink_huge_zero_folio_scan() após um get_huge_zero_folio concorrente ter instalado um valor válido nesse local.
Isso resulta em huge_zero_folio sendo definido corretamente, mas huge_zero_pfn sendo definido incorretamente; consequentemente, is_huge_zero_pfn() e, por sua vez, is_huge_zero_pmd(), identificarão erroneamente o huge zero folio como sendo um THP (Transparent Huge Page) folio comum.
Isso pode resultar no split do huge zero folio e em seu tratamento incorreto de outras formas.
A solução para isso é muito sutil, pois há um caminho rápido atômico, portanto a ordenação em arquiteturas com ordem fraca de memória deve ser tratada com extrema cautela.
O primeiro commit corrige o problema introduzindo uma spinlock ao redor das escritas em huge_zero_[pfn, folio, refcount], com consideração cuidadosa dada à ordenação load/store no caminho rápido. Ele é colocado em primeiro lugar e mantido o mais pequeno possível para que possa ser backported isoladamente.
O segundo commit é um cleanup puro que reestrutura a lógica CONFIG_PERSISTENT_HUGE_ZERO_FOLIO para separar melhor a lógica persistente da logicamente alocada dinamicamente.
Este patch (de 2):
Se !CONFIG_PERSISTENT_HUGE_ZERO_FOLIO, o huge_zero_folio possui contagem de referência gerenciada por huge_zero_refcount e é retornado por mm_get_huge_zero_folio().
Quando o chamador termina com a página zero gigante, sua contagem de referência é decrementada. Apenas um shrinker pode definir a contagem de referência como zero.
Infelizmente, uma race condition pode ocorrer entre um shrinker decrementando a contagem de referência para zero e uma page fault concorrente.
Isso ocorre porque shrink_huge_zero_folio_scan() pode, se houver azar extremo, ser preempedido entre definir huge_zero_refcount como zero e escrever um valor inválido.
Durante esse tempo, get_huge_zero_folio() poderia gravar em huge_zero_pfn antes que shrink_huge_zero_folio_scan__() retome a execução.
Nesse evento, o huge zero folio será persistentemente identificado incorretamente, fazendo com que o caminho de código THP seja acionado inadequadamente para o huge zero folio:
CPU 0 CPU 1 =======================================|================================= shrink_huge_zero_folio_scan() | atomic_cmpxchg() define refcount como 0 | xchg() define huge_zero_folio como NULL | get_huge_zero_folio() | | atomic_inc_not_zero() -> zero preempedido por um longo tempo | Aloca novo huge zero folio | | Escreve valid huge_zero_folio v | Escreve valid huge_zero_pfn Sobrescreve huge_zero_pfn com ~0UL <--- Escrita inválida!
Isso resulta em is_huge_zero_pfn() e is_huge_zero_pmd() retornando incorretamente false para uma página zero gigante, o que pode resultar em problemas como a divisão incorreta do huge zero folio.
Observe que o problema está com huge_zero_pfn, não com huge_zero_folio, pois get_huge_zero_folio() usa cmpxchg() condicionado ao huge_zero_folio ser NULL, com um loop de retry, e shrink_huge_zero_folio_scan() usa xchg() para definir huge_zero_folio.
Corrige o problema introduzindo uma spinlock, huge_zero_lock, para prevenir a escrita concorrente em huge_zero_folio, huge_zero_pfn e huge_zero_refcount.
É necessário tomar cuidado significativo aqui para garantir a correção:
O caminho rápido em get_huge_zero_folio() usa atomic_inc_not_zero(), que está fora da seção crítica, o que significa que a alocação de zero gigante é condicionada à huge_zero_refcount ser zero.
O caminho rápido não utiliza huge_zero_lock, portanto a seção crítica é irrelevante para ele.
Assim, são necessários invariantes - huge_zero_refcount DEVE:
* Ser definido apenas na seção crítica da huge_zero_lock para garantir a serialização de huge_zero_pfn, huge_zero_folio e ---truncado---
Several companies clearly confirm that VulDB is the primary source for best vulnerability data.