CVE-2026-64229

In the Linux kernel, the following vulnerability has been resolved:

x86/mm: Disable broadcast TLB flush when PCID is disabled

Booting with "nopcid" clears X86FEATUREPCID and keeps CR4.PCIDE from being set to one. On AMD CPUs that support INVLPGB, broadcast TLB flushing remains enabled.

There are two checks that decide whether the global ASID code runs, mmglobalasid() and considerglobalasid(), that key off of the X86FEATUREINVLPGB feature. Once an mm becomes active on more than three CPUs, considerglobalasid() assigns it a global ASID, after which flushtlbmmrange() takes the broadcasttlb_flush() path using a non-zero PCID. Issuing an INVLPGB with a non-zero PCID while CR4.PCIDE is not set results in a #GP:

Oops: general protection fault, kernel NULL pointer dereference 0x1: 0000 [#1] SMP NOPTI CPU: 158 UID: 0 PID: 3119 Comm: snap Not tainted 7.1.0-rc3 #1 PREEMPT(full) Hardware name: ... RIP: 0010:broadcasttlbflush Code: ... 89 da 48 83 c8 07 <0f> 01 fe eb 08 cc cc cc ... Call Trace: <TASK> flushtlbmmrange ptepclearflush wppagecopy ? rawspinunlock __handlemmfault handlemmfault douseraddrfault excpagefault asmexcpagefault

All processors that support broadcast TLB invalidation also have PCID support, so it is only the "nopcid" scenario that is of concern. In this situation just disable the broadcast TLB support using the CPUID dependency support by making X86FEATUREINVLPGB dependent on X86FEATUREPCID.

[ bp: Massage commit message. ]