s390/mm: four page table levels vs. fork
authorMartin Schwidefsky <schwidefsky@de.ibm.com>
Mon, 15 Feb 2016 13:46:49 +0000 (14:46 +0100)
committerMartin Schwidefsky <schwidefsky@de.ibm.com>
Thu, 10 Mar 2016 08:21:24 +0000 (09:21 +0100)
commit3446c13b268af86391d06611327006b059b8bab1
treed321bf624bb2e937e806dd565c6de3d3a8d83e36
parent7a76aa95f6f6682db5629449d763251d1c9f8c4e
s390/mm: four page table levels vs. fork

The fork of a process with four page table levels is broken since
git commit 6252d702c5311ce9 "[S390] dynamic page tables."

All new mm contexts are created with three page table levels and
an asce limit of 4TB. If the parent has four levels dup_mmap will
add vmas to the new context which are outside of the asce limit.
The subsequent call to copy_page_range will walk the three level
page table structure of the new process with non-zero pgd and pud
indexes. This leads to memory clobbers as the pgd_index *and* the
pud_index is added to the mm->pgd pointer without a pgd_deref
in between.

The init_new_context() function is selecting the number of page
table levels for a new context. The function is used by mm_init()
which in turn is called by dup_mm() and mm_alloc(). These two are
used by fork() and exec(). The init_new_context() function can
distinguish the two cases by looking at mm->context.asce_limit,
for fork() the mm struct has been copied and the number of page
table levels may not change. For exec() the mm_alloc() function
set the new mm structure to zero, in this case a three-level page
table is created as the temporary stack space is located at
STACK_TOP_MAX = 4TB.

This fixes CVE-2016-2143.

Reported-by: Marcin Koƛcielnicki <koriakin@0x04.net>
Reviewed-by: Heiko Carstens <heiko.carstens@de.ibm.com>
Cc: stable@vger.kernel.org
Signed-off-by: Martin Schwidefsky <schwidefsky@de.ibm.com>
arch/s390/include/asm/mmu_context.h
arch/s390/include/asm/pgalloc.h