https://vulnerability.circl.lu Contains only the most 10 recent sightings. http://www.rssboard.org/rss-specification python-feedgen en Thu, 07 May 2026 02:53:47 +0000 https://vulnerability.circl.lu/sighting/8ffba2ed-fb0c-4a2f-933f-6e83815964e4/export {"uuid": "8ffba2ed-fb0c-4a2f-933f-6e83815964e4", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "9f56dd64-161d-43a6-b9c3-555944290a09", "vulnerability": "CVE-2025-37964", "type": "published-proof-of-concept", "source": "https://t.me/DarkWebInformer_CVEAlerts/17019", "content": "\ud83d\udd17 DarkWebInformer.com - Cyber Threat Intelligence\n\ud83d\udccc CVE ID: CVE-2025-37964\n\ud83d\udd25 CVSS Score: N/A\n\ud83d\udd39 Description: In the Linux kernel, the following vulnerability has been resolved:\n\nx86/mm: Eliminate window where TLB flushes may be inadvertently skipped\n\ntl;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.\n\nLong Version:\n\n=== History ===\n\nThere were a few things leading up to this.\n\nFirst, 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.\n\n=== Problem ===\n\nThe too-aggressive code in should_flush_tlb() strikes in this window:\n\n // Turn on IPIs for this CPU/mm combination, but only\n // if should_flush_tlb() agrees:\n cpumask_set_cpu(cpu, mm_cpumask(next));\n\n next_tlb_gen = atomic64_read(&next->context.tlb_gen);\n choose_new_asid(next, next_tlb_gen, &new_asid, &need_flush);\n load_new_mm_cr3(need_flush);\n // ^ After 'need_flush' is set to false, IPIs *MUST*\n // be sent to this CPU and not be ignored.\n\n this_cpu_write(cpu_tlbstate.loaded_mm, next);\n // ^ Not until this point does should_flush_tlb()\n // become true!\n\nshould_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.\n\n=== Solution ===\n\nThankfully, 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.\n\nThis 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.\n\nUpdate the comment where LOADED_MM_SWITCHING is written since it grew\nyet another user.\n\nPeter 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\ud83d\udccf Published: 2025-05-20T16:01:56.013Z\n\ud83d\udccf Modified: 2025-05-20T16:01:56.013Z\n\ud83d\udd17 References:\n1. https://git.kernel.org/stable/c/12f703811af043d32b1c8a30001b2fa04d5cd0ac\n2. https://git.kernel.org/stable/c/02ad4ce144bd27f71f583f667fdf3b3ba0753477\n3. https://git.kernel.org/stable/c/d41072906abec8bb8e01ed16afefbaa558908c89\n4. https://git.kernel.org/stable/c/d87392094f96e162fa5fa5a8640d70cc0952806f\n5. https://git.kernel.org/stable/c/399ec9ca8fc4999e676ff89a90184ec40031cf59\n6. https://git.kernel.org/stable/c/fea4e317f9e7e1f449ce90dedc27a2d2a95bee5a", "creation_timestamp": "2025-05-20T16:41:12.000000Z"} {"uuid": "8ffba2ed-fb0c-4a2f-933f-6e83815964e4", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "9f56dd64-161d-43a6-b9c3-555944290a09", "vulnerability": "CVE-2025-37964", "type": "published-proof-of-concept", "source": "https://t.me/DarkWebInformer_CVEAlerts/17019", "content": "\ud83d\udd17 DarkWebInformer.com - Cyber Threat Intelligence\n\ud83d\udccc CVE ID: CVE-2025-37964\n\ud83d\udd25 CVSS Score: N/A\n\ud83d\udd39 Description: In the Linux kernel, the following vulnerability has been resolved:\n\nx86/mm: Eliminate window where TLB flushes may be inadvertently skipped\n\ntl;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.\n\nLong Version:\n\n=== History ===\n\nThere were a few things leading up to this.\n\nFirst, 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.\n\n=== Problem ===\n\nThe too-aggressive code in should_flush_tlb() strikes in this window:\n\n // Turn on IPIs for this CPU/mm combination, but only\n // if should_flush_tlb() agrees:\n cpumask_set_cpu(cpu, mm_cpumask(next));\n\n next_tlb_gen = atomic64_read(&next->context.tlb_gen);\n choose_new_asid(next, next_tlb_gen, &new_asid, &need_flush);\n load_new_mm_cr3(need_flush);\n // ^ After 'need_flush' is set to false, IPIs *MUST*\n // be sent to this CPU and not be ignored.\n\n this_cpu_write(cpu_tlbstate.loaded_mm, next);\n // ^ Not until this point does should_flush_tlb()\n // become true!\n\nshould_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.\n\n=== Solution ===\n\nThankfully, 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.\n\nThis 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.\n\nUpdate the comment where LOADED_MM_SWITCHING is written since it grew\nyet another user.\n\nPeter 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\ud83d\udccf Published: 2025-05-20T16:01:56.013Z\n\ud83d\udccf Modified: 2025-05-20T16:01:56.013Z\n\ud83d\udd17 References:\n1. https://git.kernel.org/stable/c/12f703811af043d32b1c8a30001b2fa04d5cd0ac\n2. https://git.kernel.org/stable/c/02ad4ce144bd27f71f583f667fdf3b3ba0753477\n3. https://git.kernel.org/stable/c/d41072906abec8bb8e01ed16afefbaa558908c89\n4. https://git.kernel.org/stable/c/d87392094f96e162fa5fa5a8640d70cc0952806f\n5. https://git.kernel.org/stable/c/399ec9ca8fc4999e676ff89a90184ec40031cf59\n6. https://git.kernel.org/stable/c/fea4e317f9e7e1f449ce90dedc27a2d2a95bee5a", "creation_timestamp": "2025-05-20T16:41:12.000000Z"} https://vulnerability.circl.lu/sighting/8ffba2ed-fb0c-4a2f-933f-6e83815964e4/export Tue, 20 May 2025 16:41:12 +0000