CVE-2026-74674 in Linux
Summary
by MITRE • 08/22/2026
In the Linux kernel, the following vulnerability has been resolved:
mm: fix incorrect flush address in direct page table reclaim
When zap_pte_range reclaims a page table, it does:
pte_free_tlb(tlb, pmd_pgtable(pmdval), addr);
and this is unconditionally wrong: if this code executes, addr *always* points one past the end of the range covered by the table. The addr parameter is used to flush the TLB (really the paging-structure-cache) to drop references to the to-be-freed table, and any architecture that cares about the parameter will flush the wrong address. (But they'll still free the correct page).
I think it's worth contemplating why the kernel works at all.
If we hit the offending line of code, we will first clear the PMD entry (line 1954, zap_empty_pte_table), then we will issue pending flushes if force_flush is set (tlb_flush_mmu_tlbonly(tlb)), then we will skip the retry on line 1979 (phew!), and then we will do the offending pte_free_tlb call. *Or* we will clear the PMD entry immediately before pte_free_tlb (line 1983, zap_pte_table_if_empty).
If we have any pending flushes (i.e. we actually zapped any last-level entries) at the time we clear the PMD entry, then the flush really ought to flush all references to the table (Linus certainly seems to think it will on all architectures [0]).
The condition under which we have no accumulated flushes at the time of the clear is very complex (the whole zap_pte_range function has absurdly complex control flow). If we do hit the bad case, then we will end up clearing the PMD entry after the last time the range is flushed, and any CPU is free to cache a reference to the (empty) page table. If this happens due to an ordinary read or write, it would segfault, so it would be rare. But the cache could be speculatively filled as well. Then we'll flush the wrong address and then free and possibly reuse the table.
On x86, even flushing the wrong address works on non-KPTI Intel systems because INVLPG flushes *all* paging-structure-caches, not just the ones for the target address. But INVPCID does not, and flush_tlb_one_user will use INVPCID if it's available. And then we're toast. AMD systems are more susceptible: we set the EFER.TCE bit, which makes even INVLPG only flush the target address.
I think this might fix an issue in ripgrep reported here: https://github.com/BurntSushi/ripgrep/issues/3494
[0] https://lore.kernel.org/all/CA+55aFzBggoXtNXQeng5d_mRoDnaMBE5Y+URs+PHR67nUpMtaw@mail.gmail.com/T/#u
If you want to get best quality of vulnerability data, you may have to visit VulDB.
Analysis
by VulDB Data Team • 08/22/2026
The Linux kernel contains a critical flaw in the direct page table reclaim logic within the memory management subsystem, specifically involving incorrect address handling during TLB and paging-structure-cache flushes. When the zap_pte_range function reclaims a page table, it invokes pte_free_tlb with an addr parameter that unconditionally points one past the end of the range covered by the table being freed. This offset error means that any architecture relying on this address to invalidate specific cache entries will target the wrong memory location rather than the actual page table structure under reclamation. While the kernel correctly frees the physical page associated with the table, the failure to properly flush references from CPU caches can leave stale mappings in place, creating a window where speculative execution or subsequent accesses might interact with freed and potentially reused memory structures.
The operational impact of this vulnerability is contingent on specific architectural behaviors regarding how TLB invalidation instructions are implemented. On non-KPTI Intel systems using INVLPG, the instruction typically flushes all paging-structure caches regardless of the target address, which masks the bug in many common configurations. However, modern processors utilizing INVPCID for finer-grained TLB flushing do not exhibit this broad behavior; they only invalidate entries matching the specified address. Consequently, when flush_tlb_one_user employs INVPCID on compatible hardware, or on AMD systems where the EFER.TCE bit is set to restrict INVLPG to target-specific invalidation, the incorrect address results in a failure to clear stale references. This leaves CPUs free to cache references to an empty page table that has already been freed and potentially reallocated for other purposes.
The security implications of this flaw are significant as they relate directly to memory safety and speculative execution side-channels. If a CPU caches a reference to the reclaimed, now-reused page table due to insufficient flushing, subsequent ordinary read or write operations targeting addresses within that range could result in segmentation faults if the mappings no longer exist. More critically, speculative execution paths might access these stale entries before they are corrected, potentially leading to information disclosure vulnerabilities similar to those exploited by Spectre variants. The complexity of the control flow in zap_pte_range makes it difficult to predict exactly when this race condition occurs, but its occurrence during normal operation or under specific workload conditions could allow an attacker to infer kernel memory contents or cause denial-of-service through instability.
This vulnerability is categorized under CWE-362: Concurrent Execution Using Shared Resource with Improper Synchronization of References, as it involves a race between cache invalidation and resource reclamation where the synchronization mechanism (the TLB flush) targets the wrong identifier. From an ATT&CK perspective, this aligns with T1047: Windows or Linux System Discovery if exploited for information gathering via side channels, though its primary classification is in memory corruption and privilege escalation vectors due to the potential for use-after-free scenarios involving kernel data structures. The issue highlights the fragility of low-level memory management code where architectural assumptions about hardware behavior must be strictly validated across diverse CPU families.
Mitigation strategies primarily involve applying the upstream Linux kernel patch that corrects the address passed to pte_free_tlb, ensuring it points to the actual start of the page table range rather than one past its end. System administrators should ensure their kernels are updated to versions containing this fix, particularly if they operate on AMD hardware or Intel systems with INVPCID enabled. For environments where immediate patching is not feasible, disabling features that trigger aggressive TLB flushing optimizations may reduce exposure, though this impacts performance. Long-term remediation requires rigorous static analysis and architectural verification of memory management code to prevent similar off-by-one errors in cache invalidation logic across different processor architectures.