No kernel Linux, a seguinte vulnerabilidade foi resolvida. mm: corrigir endereço de descarga incorreto na recuperação da tabela de página direta Quando zap_pte_range recupera uma tabela de página, ela faz. pte_free_tlb(tlb, pmd_pgtable(pmdval), addr); e isso é incondicionalmente errado: se este código executar, ad addr * sempre* aponta um após o fim do intervalo coberto pela tabela. O parâmetro addr é usado para lavar o TLB (realmente o cache- estrutura de busca) para soltar referências para a tabela a ser libertada, e qualquer arquitetura que se importe com o parâmetro irá lavar o endereço errado. (Mas eles ainda vão libertar a página correta).
Acho que vale a pena contemplar por que o kernel funciona. Se acertarmos na linha de código ofensivo, primeiro limparemos a entrada PMD (linha) 1954, zap_vacu_pte_table), então vamos emitir flushes pendentes se force_flush estiver configurado (tlb_flush_mmu_tlbonly(tlb)), então vamos pular o re- tentação na linha 1979 (phew!), e então faremos a chamada pte_free_tlb ofensivo. *Ou* vamos limpar a entrada PMD imediatamente antes de pte_free_tlb (linha 1983, zap_pte_table_if_ vazio. Se tivermos alguma descarga pendente (ou seja, nós realmente zapped quaisquer entradas de último nível) no momento em que limpamos a entrada PMD, então a descarga realmente deve lavar todas as referências à tabela (Linus certamente parece pensar que vai em todas as arquiteturas [ 0 ]).
A condição sob a qual não temos flushes acumulados no momento do clare é muito complexa (a função toda zap_pte_range tem fluxo de controle absurdamente complexo). Se acertarmos no caso ruim, então acabaremos limpando a entrada do PMD após a última vez que o intervalo for vazado, e qualquer CPU estará livre para esconder uma referência à tabela de página (vazia). Se isso acontecer devido a uma leitura ou escrita ordinária, seria segfault, então seria raro. Mas o cache poderia ser preenchido especulativamente também. Então, vamos lavar o endereço errado e depois, livre e possivelmente reutilizar a tabela. Em x 86, mesmo a descarga do endereço errado funciona em sistemas Intel não- KPTI porque o INVLPG elimina * todos os caches- estrutura- de- chamadas, não apenas os do endereço- alvo. Mas o INVPCID não funciona, e o wrestling_tlb_one_user usará o INVPCID se estiver disponível. E então estamos torrados. Os sistemas AMD são mais suscetíveis: definimos o bit EFER.TCE, o que faz com que até mesmo o INVLPG apenas lave o endereço alvo.
Acho que isso pode corrigir um problema no rippep relatado aqui: 3494. [ 0 ] 55 aFzBggoXtNXQeng 5 d_ mRoDnaMBE 5 Y+URs+PHR 67 nUpMtaw@mail.gmail.com/T/#u Registro de aconselhamento: GHSA- h 8 c 5 - 5 mw 2 - 4 jr 4. Identificadores relacionados: CVE- 2026 - 74674.
Tempo: GitHub Advisory Database publicou este registro em 2026 - 08 - 22 T 18: 30: 28.000 Z e lista a sua última modificação como 2026 - 08 - 25 T 06: 31: 27.000 Z. Severidade: ALTAMENTE. Dados de pontuação publicados: CVSS_V 3: CVSS: 3.1 /AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H.
Software afetado: o registro de aconselhamento não fornece um pacote normalizado ou faixa de versões. Classificação e evidência: nenhum identificador CWE está listado. O registro contém 3 suporte de referências nestes tipos: AVISO, WEB.