← Back to team overview

kernel-packages team mailing list archive

[Bug 1556141] Re: s390/mm: four page table levels vs. fork

 

** Also affects: linux (Ubuntu Xenial)
   Importance: Undecided
     Assignee: Skipper Bug Screeners (skipper-screen-team)
       Status: New

** Changed in: linux (Ubuntu Xenial)
       Status: New => Fix Committed

** Changed in: linux (Ubuntu Xenial)
     Assignee: Skipper Bug Screeners (skipper-screen-team) => Tim Gardner (timg-tpi)

** CVE added: http://www.cve.mitre.org/cgi-
bin/cvename.cgi?name=2016-2143

-- 
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to linux in Ubuntu.
https://bugs.launchpad.net/bugs/1556141

Title:
  s390/mm: four page table levels vs. fork

Status in linux package in Ubuntu:
  Fix Committed
Status in linux source package in Xenial:
  Fix Committed

Bug description:
  == Comment: #0 - Hendrik Brueckner <brueckner@xxxxxxxxxx> - 2016-03-11 08:30:57 ==
  Please backport:

  http://git.kernel.org/cgit/linux/kernel/git/s390/linux.git/commit/?h
  =for-linus&id=3446c13b268af86391d06611327006b059b8bab1

  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@xxxxxxxx>
  Reviewed-by: Heiko Carstens <heiko.carstens@xxxxxxxxxx>
  Cc: stable@xxxxxxxxxxxxxxx
  Signed-off-by: Martin Schwidefsky <schwidefsky@xxxxxxxxxx>

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1556141/+subscriptions