** Description changed:
+ == 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.schae...@de.ibm.com>
+ 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.
+ 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().
+ also done in gup_pte_range() and gup_huge_pud().
Reproduction: Async I/O workload on buffers that are mapped as transparent
- hugepages.
+ hugepages.
Upstream-ID: ba385c0594e723d41790ecfb12c610e6f90c7785
--
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/1730596
Title:
s390/mm: fix write access check in gup_huge_pmd()
Status in Ubuntu on IBM z Systems:
In Progress
Status in linux package in Ubuntu:
Fix Committed
Status in linux source package in Xenial:
In Progress
Status in linux source package in Zesty:
In Progress
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.schae...@de.ibm.com>
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
--
Mailing list: https://launchpad.net/~kernel-packages
Post to : kernel-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kernel-packages
More help : https://help.launchpad.net/ListHelp
