CVE-2026-64229

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> x86/mm: Disable broadcast TLB flush when PCID is disabled<br /> <br /> Booting with "nopcid" clears X86_FEATURE_PCID and keeps CR4.PCIDE from being<br /> set to one. On AMD CPUs that support INVLPGB, broadcast TLB flushing remains<br /> enabled.<br /> <br /> There are two checks that decide whether the global ASID code runs,<br /> mm_global_asid() and consider_global_asid(), that key off of the<br /> X86_FEATURE_INVLPGB feature. Once an mm becomes active on more than three<br /> CPUs, consider_global_asid() assigns it a global ASID, after which<br /> flush_tlb_mm_range() takes the broadcast_tlb_flush() path using a non-zero<br /> PCID. Issuing an INVLPGB with a non-zero PCID while CR4.PCIDE is not set<br /> results in a #GP:<br /> <br /> Oops: general protection fault, kernel NULL pointer dereference 0x1: 0000 [#1] SMP NOPTI<br /> CPU: 158 UID: 0 PID: 3119 Comm: snap Not tainted 7.1.0-rc3 #1 PREEMPT(full)<br /> Hardware name: ...<br /> RIP: 0010:broadcast_tlb_flush<br /> Code: ... 89 da 48 83 c8 07 01 fe eb 08 cc cc cc ...<br /> Call Trace:<br /> <br /> flush_tlb_mm_range<br /> ptep_clear_flush<br /> wp_page_copy<br /> ? _raw_spin_unlock<br /> __handle_mm_fault<br /> handle_mm_fault<br /> do_user_addr_fault<br /> exc_page_fault<br /> asm_exc_page_fault<br /> <br /> All processors that support broadcast TLB invalidation also have PCID support,<br /> so it is only the "nopcid" scenario that is of concern. In this situation just<br /> disable the broadcast TLB support using the CPUID dependency support by making<br /> X86_FEATURE_INVLPGB dependent on X86_FEATURE_PCID.<br /> <br /> [ bp: Massage commit message. ]