cve/published/2025/CVE-2025-37964.mbox - pub/scm/linux/security/vulns - Git at Google

 From bippy-1.2.0 Mon Sep 17 00:00:00 2001
 From: Greg Kroah-Hartman <gregkh@kernel.org>
 To: <linux-cve-announce@vger.kernel.org>
 Reply-to: <cve@kernel.org>, <linux-kernel@vger.kernel.org>
 Subject: CVE-2025-37964: x86/mm: Eliminate window where TLB flushes may be inadvertently skipped

 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 should be getting TLB flushes for the new mm.  But
 should_flush_tlb() has a bug and suppresses the flush.  Fix it by
 widening the window where should_flush_tlb() sends an IPI.

 Long Version:

 === History ===

 There were a few things leading up to this.

 First, updating mm_cpumask() was observed to be too expensive, so it was
 made lazier.  But being lazy caused too many unnecessary IPIs to CPUs
 due to the now-lazy mm_cpumask().  So code was added to cull
 mm_cpumask() periodically[2].  But that culling was a bit too aggressive
 and skipped sending TLB flushes to CPUs that need them.  So here we are
 again.

 === Problem ===

 The too-aggressive code in should_flush_tlb() strikes in this window:

 	// Turn on IPIs for this CPU/mm combination, but only
 	// if should_flush_tlb() agrees:
 	cpumask_set_cpu(cpu, mm_cpumask(next));

 	next_tlb_gen = atomic64_read(&next->context.tlb_gen);
 	choose_new_asid(next, next_tlb_gen, &new_asid, &need_flush);
 	load_new_mm_cr3(need_flush);
 	// ^ After 'need_flush' is set to false, IPIs *MUST*
 	// be sent to this CPU and not be ignored.

         this_cpu_write(cpu_tlbstate.loaded_mm, next);
 	// ^ Not until this point does should_flush_tlb()
 	// become true!

 should_flush_tlb() will suppress TLB flushes between load_new_mm_cr3()
 and writing to 'loaded_mm', which is a window where they should not be
 suppressed.  Whoops.

 === Solution ===

 Thankfully, the fuzzy "just about to write CR3" window is already marked
 with loaded_mm==LOADED_MM_SWITCHING.  Simply checking for that state in
 should_flush_tlb() is sufficient to ensure that the CPU is targeted with
 an IPI.

 This will cause more TLB flush IPIs.  But the window is relatively small
 and I do not expect this to cause any kind of measurable performance
 impact.

 Update the comment where LOADED_MM_SWITCHING is written since it grew
 yet another user.

 Peter Z also raised a concern that should_flush_tlb() might not observe
 'loaded_mm' and 'is_lazy' in the same order that switch_mm_irqs_off()
 writes them.  Add a barrier to ensure that they are observed in the
 order they are written.

 The Linux kernel CVE team has assigned CVE-2025-37964 to this issue.


 Affected and fixed versions
 ===========================

 	Issue introduced in 5.15.179 with commit 848b5815177582de0e1d0118725378e0fbadca20 and fixed in 5.15.183 with commit 12f703811af043d32b1c8a30001b2fa04d5cd0ac
 	Issue introduced in 6.1.129 with commit b47002ed65ade940839b7f439ff4a194e7d5ec28 and fixed in 6.1.139 with commit 02ad4ce144bd27f71f583f667fdf3b3ba0753477
 	Issue introduced in 6.6.79 with commit a04fe3bfc71e28009e20357b79df1e8ef7c9d600 and fixed in 6.6.91 with commit d41072906abec8bb8e01ed16afefbaa558908c89
 	Issue introduced in 6.12.16 with commit 3dbe889a1b829b4c07e0836ff853fe649e51ce4f and fixed in 6.12.29 with commit d87392094f96e162fa5fa5a8640d70cc0952806f
 	Issue introduced in 6.14 with commit 6db2526c1d694c91c6e05e2f186c085e9460f202 and fixed in 6.14.7 with commit 399ec9ca8fc4999e676ff89a90184ec40031cf59
 	Issue introduced in 6.14 with commit 6db2526c1d694c91c6e05e2f186c085e9460f202 and fixed in 6.15 with commit fea4e317f9e7e1f449ce90dedc27a2d2a95bee5a
 	Issue introduced in 6.13.4 with commit d1347977661342cb09a304a17701eb2d4aa21dec

 Please see https://www.kernel.org for a full list of currently supported
 kernel versions by the kernel community.

 Unaffected versions might change over time as fixes are backported to
 older supported kernel versions.  The official CVE entry at
 	https://cve.org/CVERecord/?id=CVE-2025-37964
 will be updated if fixes are backported, please check that for the most
 up to date information about this issue.


 Affected files
 ==============

 The file(s) affected by this issue are:
 	arch/x86/mm/tlb.c


 Mitigation
 ==========

 The Linux kernel CVE team recommends that you update to the latest
 stable kernel version for this, and many other bugfixes.  Individual
 changes are never tested alone, but rather are part of a larger kernel
 release.  Cherry-picking individual commits is not recommended or
 supported by the Linux kernel community at all.  If however, updating to
 the latest release is impossible, the individual changes to resolve this
 issue can be found at these commits:
 	https://git.kernel.org/stable/c/12f703811af043d32b1c8a30001b2fa04d5cd0ac
 	https://git.kernel.org/stable/c/02ad4ce144bd27f71f583f667fdf3b3ba0753477
 	https://git.kernel.org/stable/c/d41072906abec8bb8e01ed16afefbaa558908c89
 	https://git.kernel.org/stable/c/d87392094f96e162fa5fa5a8640d70cc0952806f
 	https://git.kernel.org/stable/c/399ec9ca8fc4999e676ff89a90184ec40031cf59
 	https://git.kernel.org/stable/c/fea4e317f9e7e1f449ce90dedc27a2d2a95bee5a
	From bippy-1.2.0 Mon Sep 17 00:00:00 2001
	From: Greg Kroah-Hartman <gregkh@kernel.org>
	To: <linux-cve-announce@vger.kernel.org>
	Reply-to: <cve@kernel.org>, <linux-kernel@vger.kernel.org>
	Subject: CVE-2025-37964: x86/mm: Eliminate window where TLB flushes may be inadvertently skipped

	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 should be getting TLB flushes for the new mm. But
	should_flush_tlb() has a bug and suppresses the flush. Fix it by
	widening the window where should_flush_tlb() sends an IPI.

	Long Version:

	=== History ===

	There were a few things leading up to this.

	First, updating mm_cpumask() was observed to be too expensive, so it was
	made lazier. But being lazy caused too many unnecessary IPIs to CPUs
	due to the now-lazy mm_cpumask(). So code was added to cull
	mm_cpumask() periodically[2]. But that culling was a bit too aggressive
	and skipped sending TLB flushes to CPUs that need them. So here we are
	again.

	=== Problem ===

	The too-aggressive code in should_flush_tlb() strikes in this window:

	// Turn on IPIs for this CPU/mm combination, but only
	// if should_flush_tlb() agrees:
	cpumask_set_cpu(cpu, mm_cpumask(next));

	next_tlb_gen = atomic64_read(&next->context.tlb_gen);
	choose_new_asid(next, next_tlb_gen, &new_asid, &need_flush);
	load_new_mm_cr3(need_flush);
	// ^ After 'need_flush' is set to false, IPIs MUST
	// be sent to this CPU and not be ignored.

	this_cpu_write(cpu_tlbstate.loaded_mm, next);
	// ^ Not until this point does should_flush_tlb()
	// become true!

	should_flush_tlb() will suppress TLB flushes between load_new_mm_cr3()
	and writing to 'loaded_mm', which is a window where they should not be
	suppressed. Whoops.

	=== Solution ===

	Thankfully, the fuzzy "just about to write CR3" window is already marked
	with loaded_mm==LOADED_MM_SWITCHING. Simply checking for that state in
	should_flush_tlb() is sufficient to ensure that the CPU is targeted with
	an IPI.

	This will cause more TLB flush IPIs. But the window is relatively small
	and I do not expect this to cause any kind of measurable performance
	impact.

	Update the comment where LOADED_MM_SWITCHING is written since it grew
	yet another user.

	Peter Z also raised a concern that should_flush_tlb() might not observe
	'loaded_mm' and 'is_lazy' in the same order that switch_mm_irqs_off()
	writes them. Add a barrier to ensure that they are observed in the
	order they are written.

	The Linux kernel CVE team has assigned CVE-2025-37964 to this issue.


	Affected and fixed versions
	===========================

	Issue introduced in 5.15.179 with commit 848b5815177582de0e1d0118725378e0fbadca20 and fixed in 5.15.183 with commit 12f703811af043d32b1c8a30001b2fa04d5cd0ac
	Issue introduced in 6.1.129 with commit b47002ed65ade940839b7f439ff4a194e7d5ec28 and fixed in 6.1.139 with commit 02ad4ce144bd27f71f583f667fdf3b3ba0753477
	Issue introduced in 6.6.79 with commit a04fe3bfc71e28009e20357b79df1e8ef7c9d600 and fixed in 6.6.91 with commit d41072906abec8bb8e01ed16afefbaa558908c89
	Issue introduced in 6.12.16 with commit 3dbe889a1b829b4c07e0836ff853fe649e51ce4f and fixed in 6.12.29 with commit d87392094f96e162fa5fa5a8640d70cc0952806f
	Issue introduced in 6.14 with commit 6db2526c1d694c91c6e05e2f186c085e9460f202 and fixed in 6.14.7 with commit 399ec9ca8fc4999e676ff89a90184ec40031cf59
	Issue introduced in 6.14 with commit 6db2526c1d694c91c6e05e2f186c085e9460f202 and fixed in 6.15 with commit fea4e317f9e7e1f449ce90dedc27a2d2a95bee5a
	Issue introduced in 6.13.4 with commit d1347977661342cb09a304a17701eb2d4aa21dec

	Please see https://www.kernel.org for a full list of currently supported
	kernel versions by the kernel community.

	Unaffected versions might change over time as fixes are backported to
	older supported kernel versions. The official CVE entry at
	https://cve.org/CVERecord/?id=CVE-2025-37964
	will be updated if fixes are backported, please check that for the most
	up to date information about this issue.


	Affected files
	==============

	The file(s) affected by this issue are:
	arch/x86/mm/tlb.c


	Mitigation
	==========

	The Linux kernel CVE team recommends that you update to the latest
	stable kernel version for this, and many other bugfixes. Individual
	changes are never tested alone, but rather are part of a larger kernel
	release. Cherry-picking individual commits is not recommended or
	supported by the Linux kernel community at all. If however, updating to
	the latest release is impossible, the individual changes to resolve this
	issue can be found at these commits:
	https://git.kernel.org/stable/c/12f703811af043d32b1c8a30001b2fa04d5cd0ac
	https://git.kernel.org/stable/c/02ad4ce144bd27f71f583f667fdf3b3ba0753477
	https://git.kernel.org/stable/c/d41072906abec8bb8e01ed16afefbaa558908c89
	https://git.kernel.org/stable/c/d87392094f96e162fa5fa5a8640d70cc0952806f
	https://git.kernel.org/stable/c/399ec9ca8fc4999e676ff89a90184ec40031cf59
	https://git.kernel.org/stable/c/fea4e317f9e7e1f449ce90dedc27a2d2a95bee5a