Overview
About vulnerability
In the Linux kernel, the following vulnerability has been resolved:
powerpc/64s/slb: Fix SLB multihit issue during SLB preload
On systems using the hash MMU, there is a software SLB preload cache that mirrors the entries loaded into the hardware SLB buffer. This preload cache is subject to periodic eviction — typically after every 256 context switches — to remove old entry.
To optimize performance, the kernel skips switch_mmu_context() in switch_mm_irqs_off() when the prev and next mm_struct are the same. However, on hash MMU systems, this can lead to inconsistencies between the hardware SLB and the software preload cache.
If an SLB entry for a process is evicted from the software cache on one CPU, and the same process later runs on another CPU without executing switch_mmu_context(), the hardware SLB may retain stale entries. If the kernel then attempts to reload that entry, it can trigger an SLB multi-hit error.
The following timeline shows how stale SLB entries are created and can cause a multi-hit error when a process moves between CPUs without a MMU context switch.
CPU 0 CPU 1
Process P exec swapper/1 load_elf_binary begin_new_exc activate_mm switch_mm_irqs_off switch_mmu_context switch_slb /*
- This invalidates all
- the entries in the HW
- and setup the new HW
- SLB entries as per the
- preload cache. */ context_switch sched_migrate_task migrates process P to cpu-1
Process swapper/0 context switch (to process P) (uses mm_struct of Process P) switch_mm_irqs_off() switch_slb load_slb++ /*
- load_slb becomes 0 here
- and we evict an entry from
- the preload cache with
- preload_age(). We still
- keep HW SLB and preload
- cache in sync, that is
- because all HW SLB entries
- anyways gets evicted in
- switch_slb during SLBIA.
- We then only add those
- entries back in HW SLB,
- which are currently
- present in preload_cache
- (after eviction). */ load_elf_binary continues… setup_new_exec() slb_setup_new_exec()
sched_switch event sched_migrate_task migrates process P to cpu-0
context_switch from swapper/0 to Process P switch_mm_irqs_off() /*
- Since both prev and next mm struct are same we don’t call
- switch_mmu_context(). This will cause the HW SLB and SW preload
- cache to go out of sync in preload_new_slb_context. Because there
- was an SLB entry which was evicted from both HW and preload cache
- on cpu-1. Now later in preload_new_slb_context(), when we will try
- to add the same preload entry again, we will add this to the SW
- preload cache and then will add it to the HW SLB. Since on cpu-0
- this entry was never invalidated, hence adding this entry to the HW
- SLB will cause a SLB multi-hit error. */ load_elf_binary cont —truncated—
Details
- Affected product:
- AlmaLinux 9.2 ESU , Oracle Linux 7 ELS , TuxCare 9.6 ESU , Ubuntu 20.04 ELS
- Affected packages:
- linux @ 5.4.0 (+3 more)
In the Linux kernel, the following vulnerability has been resolved:
powerpc/64s/slb: Fix SLB multihit issue during SLB preload
On systems using the hash MMU, there is a software SLB preload cache that mirrors the entries loaded into the hardware SLB buffer. This preload cache is subject to periodic eviction — typically after every 256 context switches — to remove old entry.
To optimize performance, the kernel skips switch_mmu_context() in switch_mm_irqs_off() when the prev and next mm_struct are the same. However, on hash MMU systems, this can lead to inconsistencies between the hardware SLB and the software preload cache.
If an SLB entry for a process is evicted from the software cache on one CPU, and the same process later runs on another CPU without executing switch_mmu_context(), the hardware SLB may retain stale entries. If the kernel then attempts to reload that entry, it can trigger an SLB multi-hit error.
The following timeline shows how stale SLB entries are created and can cause a multi-hit error when a process moves between CPUs without a MMU context switch.
CPU 0 CPU 1
Process P exec swapper/1 load_elf_binary begin_new_exc activate_mm switch_mm_irqs_off switch_mmu_context switch_slb /*
- This invalidates all
- the entries in the HW
- and setup the new HW
- SLB entries as per the
- preload cache. */ context_switch sched_migrate_task migrates process P to cpu-1
Process swapper/0 context switch (to process P) (uses mm_struct of Process P) switch_mm_irqs_off() switch_slb load_slb++ /*
- load_slb becomes 0 here
- and we evict an entry from
- the preload cache with
- preload_age(). We still
- keep HW SLB and preload
- cache in sync, that is
- because all HW SLB entries
- anyways gets evicted in
- switch_slb during SLBIA.
- We then only add those
- entries back in HW SLB,
- which are currently
- present in preload_cache
- (after eviction). */ load_elf_binary continues… setup_new_exec() slb_setup_new_exec()
sched_switch event sched_migrate_task migrates process P to cpu-0
context_switch from swapper/0 to Process P switch_mm_irqs_off() /*
- Since both prev and next mm struct are same we don’t call
- switch_mmu_context(). This will cause the HW SLB and SW preload
- cache to go out of sync in preload_new_slb_context. Because there
- was an SLB entry which was evicted from both HW and preload cache
- on cpu-1. Now later in preload_new_slb_context(), when we will try
- to add the same preload entry again, we will add this to the SW
- preload cache and then will add it to the HW SLB. Since on cpu-0
- this entry was never invalidated, hence adding this entry to the HW
- SLB will cause a SLB multi-hit error. */ load_elf_binary cont —truncated—