CVE-2026-74674

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> mm: fix incorrect flush address in direct page table reclaim<br /> <br /> When zap_pte_range reclaims a page table, it does:<br /> <br /> pte_free_tlb(tlb, pmd_pgtable(pmdval), addr);<br /> <br /> and this is unconditionally wrong: if this code executes, addr *always*<br /> points one past the end of the range covered by the table. The addr<br /> parameter is used to flush the TLB (really the paging-structure-cache)<br /> to drop references to the to-be-freed table, and any architecture that<br /> cares about the parameter will flush the wrong address. (But they&amp;#39;ll<br /> still free the correct page).<br /> <br /> I think it&amp;#39;s worth contemplating why the kernel works at all.<br /> <br /> If we hit the offending line of code, we will first clear the PMD entry<br /> (line 1954, zap_empty_pte_table), then we will issue pending flushes if<br /> force_flush is set (tlb_flush_mmu_tlbonly(tlb)), then we will skip the<br /> retry on line 1979 (phew!), and then we will do the offending<br /> pte_free_tlb call. *Or* we will clear the PMD entry immediately before<br /> pte_free_tlb (line 1983, zap_pte_table_if_empty).<br /> <br /> If we have any pending flushes (i.e. we actually zapped any last-level<br /> entries) at the time we clear the PMD entry, then the flush really ought<br /> to flush all references to the table (Linus certainly seems to think it<br /> will on all architectures [0]).<br /> <br /> The condition under which we have no accumulated flushes at the time of<br /> the clear is very complex (the whole zap_pte_range function has absurdly<br /> complex control flow). If we do hit the bad case, then we will end up<br /> clearing the PMD entry after the last time the range is flushed, and any<br /> CPU is free to cache a reference to the (empty) page table. If this<br /> happens due to an ordinary read or write, it would segfault, so it would<br /> be rare. But the cache could be speculatively filled as well. Then<br /> we&amp;#39;ll flush the wrong address and then free and possibly reuse the<br /> table.<br /> <br /> On x86, even flushing the wrong address works on non-KPTI Intel systems<br /> because INVLPG flushes *all* paging-structure-caches, not just the ones<br /> for the target address. But INVPCID does not, and flush_tlb_one_user<br /> will use INVPCID if it&amp;#39;s available. And then we&amp;#39;re toast. AMD systems<br /> are more susceptible: we set the EFER.TCE bit, which makes even INVLPG<br /> only flush the target address.<br /> <br /> I think this might fix an issue in ripgrep reported here:<br /> https://github.com/BurntSushi/ripgrep/issues/3494<br /> <br /> [0] https://lore.kernel.org/all/CA+55aFzBggoXtNXQeng5d_mRoDnaMBE5Y+URs+PHR67nUpMtaw@mail.gmail.com/T/#u