CVE-2026-74674 in Linux
Sumário
de VulDB • 22/08/2026
No kernel do Linux, a seguinte vulnerabilidade foi corrigida:
mm: corrige o endereço de flush incorreto na recuperação direta da tabela de páginas
Quando zap_pte_range recupera uma tabela de páginas, ele executa:
pte_free_tlb(tlb, pmd_pgtable(pmdval), addr);
E isso é incondicionalmente errado: se este código for executado, o parâmetro *addr* **sempre** aponta para um endereço após o final do intervalo coberto pela tabela. O parâmetro *addr* é usado para realizar o flush da TLB (mais precisamente, do cache de estruturas de paginação) a fim de remover as referências à tabela que está sendo liberada, e qualquer arquitetura que leve em conta esse parâmetro realizará um flush no endereço incorreto. (No entanto, elas ainda liberarão a página correta).
Acho válido considerar por que o kernel funciona de todo.
Se atingirmos a linha de código ofensiva, primeiro limparemos a entrada PMD (linha 1954, zap_empty_pte_table), em seguida emitiremos os flushs pendentes se *force_flush* estiver definido (tlb_flush_mmu_tlbonly(tlb)), depois pularemos a nova tentativa na linha 1979 (ufa!), e então executaremos a chamada ofensiva pte_free_tlb. *Ou* limparemos a entrada PMD imediatamente antes de pte_free_tlb (linha 1983, zap_pte_table_if_empty).
Se houver flushs pendentes (ou seja, se realmente tivermos apagado as entradas do último nível) no momento em que limparmos a entrada PMD, o flush deveria realmente remover todas as referências à tabela (Linus certamente acredita que isso ocorre em todas as arquiteturas [0]).
A condição sob a qual não há flushs acumulados no momento da limpeza é muito complexa (toda a função zap_pte_range possui um fluxo de controle absurdamente complexo). Se ocorrermos o caso ruim, acabaremos limpando a entrada PMD após a última vez que o intervalo foi flushed, e qualquer CPU pode armazenar em cache uma referência à tabela de páginas (vazia). Se isso acontecer devido a uma leitura ou escrita comum, causaria um segfault, portanto seria raro. Mas o cache também poderia ser preenchido especulativamente. Então, realizaremos um flush no endereço incorreto e, em seguida, liberaremos e possivelmente reutilizaremos a tabela.
No x86, mesmo realizar um flush no endereço errado funciona em sistemas Intel sem KPTI porque INVLPG faz flush de *todos* os caches de estruturas de paginação, não apenas daqueles destinados ao endereço alvo. Mas INVPCID não o faz, e flush_tlb_one_user usará INVPCID se estiver disponível. E então estamos comprometidos (toast). Sistemas AMD são mais suscetíveis: definimos o bit EFER.TCE, o que faz com que até mesmo INVLPG realize um flush apenas no endereço alvo.
Acho que isso pode corrigir uma issue relatada no ripgrep aqui: https://github.com/BurntSushi/ripgrep/issues/3494
[0] https://lore.kernel.org/all/CA+55aFzBggoXtNXQeng5d_mRoDnaMBE5Y+URs+PHR67nUpMtaw@mail.gmail.com/T/#u
Once again VulDB remains the best source for vulnerability data.