{"id":63391,"date":"2025-05-20T21:32:06","date_gmt":"2025-05-20T18:02:06","guid":{"rendered":"https:\/\/afaghhosting.net\/blog\/cve-2025-37964-linux-kernel-intel-x86-tlb-flush-inadvertent-skipping-vulnerability\/"},"modified":"2025-05-20T21:32:06","modified_gmt":"2025-05-20T18:02:06","slug":"cve-2025-37964-linux-kernel-intel-x86-tlb-flush-inadvertent-skipping-vulnerability","status":"publish","type":"post","link":"https:\/\/afaghhosting.net\/blog\/cve-2025-37964-linux-kernel-intel-x86-tlb-flush-inadvertent-skipping-vulnerability\/","title":{"rendered":"CVE-2025-37964 – Linux Kernel: Intel X86 TLB Flush Inadvertent Skipping Vulnerability"},"content":{"rendered":"

CVE ID : <\/strong>CVE-2025-37964
\n
\nPublished : <\/strong> May 20, 2025, 4:15 p.m. | 54\u00a0minutes ago
\n
\nDescription : <\/strong>In the Linux kernel, the following vulnerability has been resolved:<\/p>\n

x86\/mm: Eliminate window where TLB flushes may be inadvertently skipped<\/p>\n

tl;dr: There is a window in the mm switching code where the new CR3 is
\nset and the CPU should be getting TLB flushes for the new mm. But
\nshould_flush_tlb() has a bug and suppresses the flush. Fix it by
\nwidening the window where should_flush_tlb() sends an IPI.<\/p>\n

Long Version:<\/p>\n

=== History ===<\/p>\n

There were a few things leading up to this.<\/p>\n

First, updating mm_cpumask() was observed to be too expensive, so it was
\nmade lazier. But being lazy caused too many unnecessary IPIs to CPUs
\ndue to the now-lazy mm_cpumask(). So code was added to cull
\nmm_cpumask() periodically[2]. But that culling was a bit too aggressive
\nand skipped sending TLB flushes to CPUs that need them. So here we are
\nagain.<\/p>\n

=== Problem ===<\/p>\n

The too-aggressive code in should_flush_tlb() strikes in this window:<\/p>\n

\t\/\/ Turn on IPIs for this CPU\/mm combination, but only
\n\t\/\/ if should_flush_tlb() agrees:
\n\tcpumask_set_cpu(cpu, mm_cpumask(next));<\/p>\n

\tnext_tlb_gen = atomic64_read(&next->context.tlb_gen);
\n\tchoose_new_asid(next, next_tlb_gen, &new_asid, &need_flush);
\n\tload_new_mm_cr3(need_flush);
\n\t\/\/ ^ After ‘need_flush’ is set to false, IPIs *MUST*
\n\t\/\/ be sent to this CPU and not be ignored.<\/p>\n

this_cpu_write(cpu_tlbstate.loaded_mm, next);
\n\t\/\/ ^ Not until this point does should_flush_tlb()
\n\t\/\/ become true!<\/p>\n

should_flush_tlb() will suppress TLB flushes between load_new_mm_cr3()
\nand writing to ‘loaded_mm’, which is a window where they should not be
\nsuppressed. Whoops.<\/p>\n

=== Solution ===<\/p>\n

Thankfully, the fuzzy “just about to write CR3” window is already marked
\nwith loaded_mm==LOADED_MM_SWITCHING. Simply checking for that state in
\nshould_flush_tlb() is sufficient to ensure that the CPU is targeted with
\nan IPI.<\/p>\n

This will cause more TLB flush IPIs. But the window is relatively small
\nand I do not expect this to cause any kind of measurable performance
\nimpact.<\/p>\n

Update the comment where LOADED_MM_SWITCHING is written since it grew
\nyet another user.<\/p>\n

Peter Z also raised a concern that should_flush_tlb() might not observe
\n‘loaded_mm’ and ‘is_lazy’ in the same order that switch_mm_irqs_off()
\nwrites them. Add a barrier to ensure that they are observed in the
\norder they are written.
\n
\nSeverity:<\/strong> 0.0 | NA
\n
\nVisit the link for more details, such as CVSS details, affected products, timeline, and more…<\/p>\n","protected":false},"excerpt":{"rendered":"

CVE ID : CVE-2025-37964 Published : May 20, 2025, 4:15 p.m. | 54\u00a0minutes ago Description : In the Linux kernel, the following vulnerability has been resolved: x86\/mm: Eliminate window where TLB flushes may be inadvertently skipped tl;dr: There is a window in the mm switching code where the new CR3 is set and the CPU …<\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"closed","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[26],"tags":[],"class_list":["post-63391","post","type-post","status-publish","format-standard","hentry","category-vulnerability"],"_links":{"self":[{"href":"https:\/\/afaghhosting.net\/blog\/wp-json\/wp\/v2\/posts\/63391","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/afaghhosting.net\/blog\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/afaghhosting.net\/blog\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/afaghhosting.net\/blog\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/afaghhosting.net\/blog\/wp-json\/wp\/v2\/comments?post=63391"}],"version-history":[{"count":0,"href":"https:\/\/afaghhosting.net\/blog\/wp-json\/wp\/v2\/posts\/63391\/revisions"}],"wp:attachment":[{"href":"https:\/\/afaghhosting.net\/blog\/wp-json\/wp\/v2\/media?parent=63391"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/afaghhosting.net\/blog\/wp-json\/wp\/v2\/categories?post=63391"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/afaghhosting.net\/blog\/wp-json\/wp\/v2\/tags?post=63391"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}