]> git.itanic.dy.fi Git - linux-stable/commit
x86/mm/32: Bring back vmalloc faulting on x86_32
authorSasha Levin <sashal@kernel.org>
Mon, 7 Sep 2020 22:22:33 +0000 (18:22 -0400)
committerGreg Kroah-Hartman <gregkh@linuxfoundation.org>
Wed, 9 Sep 2020 17:14:26 +0000 (19:14 +0200)
commitdf7a510200215117436e51ad59bb051b580207d2
treecd92688c339b907e508edf3a56dfa49e830face6
parent98f0b4072c943e3b9f538792893907ccd3c523d0
x86/mm/32: Bring back vmalloc faulting on x86_32

[ Upstream commit 4819e15f740ec884a50bdc431d7f1e7638b6f7d9 ]

One can not simply remove vmalloc faulting on x86-32. Upstream

commit: 7f0a002b5a21 ("x86/mm: remove vmalloc faulting")

removed it on x86 alltogether because previously the
arch_sync_kernel_mappings() interface was introduced. This interface
added synchronization of vmalloc/ioremap page-table updates to all
page-tables in the system at creation time and was thought to make
vmalloc faulting obsolete.

But that assumption was incredibly naive.

It turned out that there is a race window between the time the vmalloc
or ioremap code establishes a mapping and the time it synchronizes
this change to other page-tables in the system.

During this race window another CPU or thread can establish a vmalloc
mapping which uses the same intermediate page-table entries (e.g. PMD
or PUD) and does no synchronization in the end, because it found all
necessary mappings already present in the kernel reference page-table.

But when these intermediate page-table entries are not yet
synchronized, the other CPU or thread will continue with a vmalloc
address that is not yet mapped in the page-table it currently uses,
causing an unhandled page fault and oops like below:

BUG: unable to handle page fault for address: fe80c000
#PF: supervisor write access in kernel mode
#PF: error_code(0x0002) - not-present page
*pde = 33183067 *pte = a8648163
Oops: 0002 [#1] SMP
CPU: 1 PID: 13514 Comm: cve-2017-17053 Tainted: G
...
Call Trace:
 ldt_dup_context+0x66/0x80
 dup_mm+0x2b3/0x480
 copy_process+0x133b/0x15c0
 _do_fork+0x94/0x3e0
 __ia32_sys_clone+0x67/0x80
 __do_fast_syscall_32+0x3f/0x70
 do_fast_syscall_32+0x29/0x60
 do_SYSENTER_32+0x15/0x20
 entry_SYSENTER_32+0x9f/0xf2
EIP: 0xb7eef549

So the arch_sync_kernel_mappings() interface is racy, but removing it
would mean to re-introduce the vmalloc_sync_all() interface, which is
even more awful. Keep arch_sync_kernel_mappings() in place and catch
the race condition in the page-fault handler instead.

Do a partial revert of above commit to get vmalloc faulting on x86-32
back in place.

Fixes: 7f0a002b5a21 ("x86/mm: remove vmalloc faulting")
Reported-by: Naresh Kamboju <naresh.kamboju@linaro.org>
Signed-off-by: Joerg Roedel <jroedel@suse.de>
Signed-off-by: Ingo Molnar <mingo@kernel.org>
Link: https://lore.kernel.org/r/20200902155904.17544-1-joro@8bytes.org
[sl: revert 7f0a002b5a21 instead to restore vmalloc faulting for x86-64]
Signed-off-by: Sasha Levin <sashal@kernel.org>
arch/x86/include/asm/switch_to.h
arch/x86/kernel/setup_percpu.c
arch/x86/mm/fault.c
arch/x86/mm/pti.c
arch/x86/mm/tlb.c