group.of.nepali.translators team mailing list archive

[Frank Heimes <1730596@xxxxxxxxxxxxxxxxxx>]

** Changed in: ubuntu-z-systems
       Status: Fix Committed => Fix Released

-- 
You received this bug notification because you are a member of नेपाली
भाषा समायोजकहरुको समूह, which is subscribed to Xenial.
Matching subscriptions: Ubuntu 16.04 Bugs
https://bugs.launchpad.net/bugs/1730596

Title:
  s390/mm: fix write access check in gup_huge_pmd()

Status in Ubuntu on IBM z Systems:
  Fix Released
Status in linux package in Ubuntu:
  Fix Committed
Status in linux source package in Xenial:
  Fix Released
Status in linux source package in Zesty:
  Fix Released
Status in linux source package in Artful:
  Fix Committed
Status in linux source package in Bionic:
  Fix Committed

Bug description:
  == SRU Justification ==
  The check for the _SEGMENT_ENTRY_PROTECT bit in gup_huge_pmd() is the
  wrong way around. It must not be set for write==1, and not be checked for
  write==0. Fix this similar to how it was fixed for ptes long time ago in
  commit 25591b0 ("[S390] fix get_user_pages_fast").

  One impact of this bug would be unnecessarily using the gup slow path for
  write==0 on r/w mappings. A potentially more severe impact would be that
  gup_huge_pmd() will succeed for write==1 on r/o mappings.

  This bug is fixed by mainline commit ba385c0594, which is in mainline
  as of v4.14-rc2.  It was also cc'd to upstream stable.  It has already
  been accepted in upstream v4.13.y, so Artful and Bionic have the fix
  via the 4.13.5 stable updates.

  == Fix ==
  commit ba385c0594e723d41790ecfb12c610e6f90c7785
  Author: Gerald Schaefer <gerald.schaefer@xxxxxxxxxx>
  Date:   Mon Sep 18 16:51:51 2017 +0200

      s390/mm: fix write access check in gup_huge_pmd()

  
  == Regression Potential ==
  This patch is specific to s390.  It has also been accepted by upstream stable, so additional upstream review has been done.


  
  Addl information

  Problem: The check for the _SEGMENT_ENTRY_PROTECT bit in
                gup_huge_pmd() is the wrong way around. It must not be set
                for write==1, and not be checked for write==0. Allowing
                write==1 with protection bit set, instead of breaking out
                to the slow path, will result in a missing faultin_page()
                to clear the protection bit (for valid writable mappings),
                and the async I/O write operation will fail to write to
                such a mapping.
  Solution:     Fix it by correctly checking the protection bit like it is
                also done in gup_pte_range() and gup_huge_pud().
  Reproduction: Async I/O workload on buffers that are mapped as transparent
                hugepages.
  Upstream-ID:  ba385c0594e723d41790ecfb12c610e6f90c7785

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu-z-systems/+bug/1730596/+subscriptions