mirror of
https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git
synced 2024-09-15 15:15:47 +00:00
371b80447f
kexec can leave MMU registers set when booting into a new kernel,
the PIDR (Process Identification Register) in particular. The boot
sequence does not zero PIDR, so it only gets set when CPUs first
switch to a userspace processes (until then it's running a kernel
thread with effective PID = 0).
This leaves a window where a process table entry and page tables are
set up due to user processes running on other CPUs, that happen to
match with a stale PID. The CPU with that PID may cause speculative
accesses that address quadrant 0 (aka userspace addresses), which will
result in cached translations and PWC (Page Walk Cache) for that
process, on a CPU which is not in the mm_cpumask and so they will not
be invalidated properly.
The most common result is the kernel hanging in infinite page fault
loops soon after kexec (usually in schedule_tail, which is usually the
first non-speculative quadrant 0 access to a new PID) due to a stale
PWC. However being a stale translation error, it could result in
anything up to security and data corruption problems.
Fix this by zeroing out PIDR at boot and kexec.
Fixes:
|
||
|---|---|---|
| .. | ||
| boot | ||
| configs | ||
| crypto | ||
| include | ||
| kernel | ||
| kvm | ||
| lib | ||
| math-emu | ||
| mm | ||
| net | ||
| oprofile | ||
| perf | ||
| platforms | ||
| purgatory | ||
| sysdev | ||
| tools | ||
| xmon | ||
| Kconfig | ||
| Kconfig.debug | ||
| Makefile | ||
| Makefile.postlink | ||