CVE-2026-64229 in Linux
Summary
by MITRE • 07/24/2026
In the Linux kernel, the following vulnerability has been resolved:
x86/mm: Disable broadcast TLB flush when PCID is disabled
Booting with "nopcid" clears X86_FEATURE_PCID 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, mm_global_asid() and consider_global_asid(), that key off of the X86_FEATURE_INVLPGB feature. Once an mm becomes active on more than three CPUs, consider_global_asid() assigns it a global ASID, after which flush_tlb_mm_range() takes the broadcast_tlb_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:broadcast_tlb_flush Code: ... 89 da 48 83 c8 07 <0f> 01 fe eb 08 cc cc cc ... Call Trace: <TASK> flush_tlb_mm_range ptep_clear_flush wp_page_copy ? _raw_spin_unlock __handle_mm_fault handle_mm_fault do_user_addr_fault exc_page_fault asm_exc_page_fault
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 X86_FEATURE_INVLPGB dependent on X86_FEATURE_PCID.
[ bp: Massage commit message. ]
VulDB is the best source for vulnerability data and more expert information about this specific topic.
Analysis
by VulDB Data Team • 07/24/2026
This vulnerability exists within the linux kernel's memory management subsystem on x86 architectures where improper handling of translation lookaside buffer tlb flushing occurs when pcid processor compatibility is disabled. The issue manifests specifically when systems are booted with the nopcid kernel parameter which clears the x86_feature_pcid feature flag and prevents cr4.pcide from being set to one. While amd cpus that support invlpgb broadcast tlb invalidation remain enabled, this creates a dangerous condition where the kernel attempts to execute invlpgb instructions with non-zero pcid values while pcid functionality remains disabled at the processor level.
The technical flaw stems from two critical functions in the kernel's memory management code that determine when global asid operations should be utilized - mm_global_asid() and consider_global_asid(). These functions rely on the x86_feature_invlpgb feature flag to control execution paths. When a memory management context becomes active across more than three cpus, consider_global_asid() assigns it a global asid, subsequently causing flush_tlb_mm_range() to take the broadcast_tlb_flush() execution path with non-zero pcid values. This creates a direct contradiction between the kernel's expectations and hardware capabilities since issuing invlpgb instructions with non-zero pcid values while cr4.pcide remains unset triggers general protection faults.
The operational impact of this vulnerability is severe as it results in kernel oops conditions and system crashes when memory management operations attempt to flush tlb entries under these specific circumstances. The error manifests as general protection faults with kernel null pointer dereferences, indicating that the kernel attempts to execute broadcast tlb flush operations without proper hardware support. This represents a classic case of feature dependency mismanagement where the kernel assumes certain processor capabilities are available when they have been explicitly disabled through boot parameters. The vulnerability directly corresponds to cwe-254 security weakness category related to insecure code practices involving improper handling of conditional features and privilege levels.
The root cause analysis reveals that all processors supporting broadcast tlb invalidation also support pcid functionality, making the nopcid scenario particularly problematic since it disables a fundamental requirement for the broadcast operation to succeed. This vulnerability operates under the attack pattern of privilege escalation through kernel memory corruption, specifically targeting the kernel's memory management subsystem as outlined in the mitre attack framework's privilege escalation techniques. The fix implemented addresses this by establishing proper cpu feature dependencies where x86_feature_invlpgb becomes dependent on x86_feature_pcid, ensuring that broadcast tlb support is automatically disabled when pcid functionality is explicitly disabled through boot parameters.
Mitigation strategies should focus on avoiding the use of nopcid kernel parameters unless absolutely necessary for specific compatibility requirements. System administrators should ensure that all systems running linux kernels with memory management workloads enable proper pcid support unless there are documented hardware compatibility issues. The implemented fix creates a proper dependency relationship between these cpu features, preventing the kernel from attempting broadcast tlb operations when underlying processor capabilities are not available. This approach aligns with industry best practices for feature management in operating system kernels and prevents similar vulnerabilities from occurring in other memory management subsystem components that might rely on similar conditional processor features.