Overview
About vulnerability
In the Linux kernel, the following vulnerability has been resolved:
x86/mm: Fix flush_tlb_range() when used for zapping normal PMDs
On the following path, flush_tlb_range() can be used for zapping normal PMD entries (PMD entries that point to page tables) together with the PTE entries in the pointed-to page table:
collapse_pte_mapped_thp pmdp_collapse_flush flush_tlb_range
The arm64 version of flush_tlb_range() has a comment describing that it can be used for page table removal, and does not use any last-level invalidation optimizations. Fix the X86 version by making it behave the same way.
Currently, X86 only uses this information for the following two purposes, which I think means the issue doesn’t have much impact:
- In native_flush_tlb_multi() for checking if lazy TLB CPUs need to be IPI’d to avoid issues with speculative page table walks.
- In Hyper-V TLB paravirtualization, again for lazy TLB stuff.
The patch “x86/mm: only invalidate final translations with INVLPGB” which is currently under review (see https://lore.kernel.org/all/[email protected]/) would probably be making the impact of this a lot worse.
Details
- Affected product:
- AlmaLinux 9.2 ESU , CentOS 8.4 ELS , CentOS 8.5 ELS , CentOS Stream 8 ELS , Oracle Linux 7 ELS , TuxCare 9.6 ESU , Ubuntu 18.04 ELS , Ubuntu 20.04 ELS
- Affected packages:
- kernel @ 5.14.0 (+7 more)
In the Linux kernel, the following vulnerability has been resolved:
x86/mm: Fix flush_tlb_range() when used for zapping normal PMDs
On the following path, flush_tlb_range() can be used for zapping normal PMD entries (PMD entries that point to page tables) together with the PTE entries in the pointed-to page table:
collapse_pte_mapped_thp pmdp_collapse_flush flush_tlb_range
The arm64 version of flush_tlb_range() has a comment describing that it can be used for page table removal, and does not use any last-level invalidation optimizations. Fix the X86 version by making it behave the same way.
Currently, X86 only uses this information for the following two purposes, which I think means the issue doesn’t have much impact:
- In native_flush_tlb_multi() for checking if lazy TLB CPUs need to be IPI’d to avoid issues with speculative page table walks.
- In Hyper-V TLB paravirtualization, again for lazy TLB stuff.
The patch “x86/mm: only invalidate final translations with INVLPGB” which is currently under review (see https://lore.kernel.org/all/[email protected]/) would probably be making the impact of this a lot worse.