[Kernel-packages] [Bug 1730596] Re: s390/mm: fix write access check in gup_huge_pmd()

[Joseph Salisbury]

** Changed in: linux (Ubuntu Artful)
   Status: Fix Committed => Fix Released

** Changed in: linux (Ubuntu Bionic)
   Status: Fix Committed => Fix Released

-- 
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:
  Fix Released
Status in linux package in Ubuntu:
  Fix Released
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 Released
Status in linux source package in Bionic:
  Fix Released

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 
  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

[Kernel-packages] [Bug 1730596] Re: s390/mm: fix write access check in gup_huge_pmd()

[Dimitri John Ledkov]

Is this fix released in artful & bionic too?

-- 
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:
  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 
  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

[Kernel-packages] [Bug 1730596] Re: s390/mm: fix write access check in gup_huge_pmd()

[Joseph Salisbury]

** Tags removed: kernel-key
** Tags added: kernel-da-key

-- 
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:
  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 
  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

[Kernel-packages] [Bug 1730596] Re: s390/mm: fix write access check in gup_huge_pmd()

[Frank Heimes]

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

-- 
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:
  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 
  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

[Kernel-packages] [Bug 1730596] Re: s390/mm: fix write access check in gup_huge_pmd()

[Launchpad Bug Tracker]

This bug was fixed in the package linux - 4.4.0-101.124

---
linux (4.4.0-101.124) xenial; urgency=low

  * linux: 4.4.0-101.124 -proposed tracker (LP: #1731264)

  * s390/mm: fix write access check in gup_huge_pmd() (LP: #1730596)
- s390/mm: fix write access check in gup_huge_pmd()

linux (4.4.0-100.123) xenial; urgency=low

  * linux: 4.4.0-100.123 -proposed tracker (LP: #1729273)

  * Xenial update to 4.4.95 stable release (LP: #1729107)
- USB: devio: Revert "USB: devio: Don't corrupt user memory"
- USB: core: fix out-of-bounds access bug in usb_get_bos_descriptor()
- USB: serial: metro-usb: add MS7820 device id
- usb: cdc_acm: Add quirk for Elatec TWN3
- usb: quirks: add quirk for WORLDE MINI MIDI keyboard
- usb: hub: Allow reset retry for USB2 devices on connect bounce
- ALSA: usb-audio: Add native DSD support for Pro-Ject Pre Box S2 Digital
- can: gs_usb: fix busy loop if no more TX context is available
- usb: musb: sunxi: Explicitly release USB PHY on exit
- usb: musb: Check for host-mode using is_host_active() on reset interrupt
- can: esd_usb2: Fix can_dlc value for received RTR, frames
- drm/nouveau/bsp/g92: disable by default
- drm/nouveau/mmu: flush tlbs before deleting page tables
- ALSA: seq: Enable 'use' locking in all configurations
- ALSA: hda: Remove superfluous '-' added by printk conversion
- i2c: ismt: Separate I2C block read from SMBus block read
- brcmsmac: make some local variables 'static const' to reduce stack size
- bus: mbus: fix window size calculation for 4GB windows
- clockevents/drivers/cs5535: Improve resilience to spurious interrupts
- rtlwifi: rtl8821ae: Fix connection lost problem
- KEYS: encrypted: fix dereference of NULL user_key_payload
- lib/digsig: fix dereference of NULL user_key_payload
- KEYS: don't let add_key() update an uninstantiated key
- pkcs7: Prevent NULL pointer dereference, since sinfo is not always set.
- parisc: Avoid trashing sr2 and sr3 in LWS code
- parisc: Fix double-word compare and exchange in LWS code on 32-bit kernels
- sched/autogroup: Fix autogroup_move_group() to never skip 
sched_move_task()
- f2fs crypto: replace some BUG_ON()'s with error checks
- f2fs crypto: add missing locking for keyring_key access
- fscrypt: fix dereference of NULL user_key_payload
- KEYS: Fix race between updating and finding a negative key
- fscrypto: require write access to mount to set encryption policy
- FS-Cache: fix dereference of NULL user_key_payload
- Linux 4.4.95

  * Xenial update to 4.4.94 stable release (LP: #1729105)
- percpu: make this_cpu_generic_read() atomic w.r.t. interrupts
- drm/dp/mst: save vcpi with payloads
- MIPS: Fix minimum alignment requirement of IRQ stack
- sctp: potential read out of bounds in sctp_ulpevent_type_enabled()
- bpf/verifier: reject BPF_ALU64|BPF_END
- udpv6: Fix the checksum computation when HW checksum does not apply
- ip6_gre: skb_push ipv6hdr before packing the header in ip6gre_header
- net: emac: Fix napi poll list corruption
- packet: hold bind lock when rebinding to fanout hook
- bpf: one perf event close won't free bpf program attached by another perf
  event
- isdn/i4l: fetch the ppp_write buffer in one shot
- vti: fix use after free in vti_tunnel_xmit/vti6_tnl_xmit
- l2tp: Avoid schedule while atomic in exit_net
- l2tp: fix race condition in l2tp_tunnel_delete
- tun: bail out from tun_get_user() if the skb is empty
- packet: in packet_do_bind, test fanout with bind_lock held
- packet: only test po->has_vnet_hdr once in packet_snd
- net: Set sk_prot_creator when cloning sockets to the right proto
- tipc: use only positive error codes in messages
- Revert "bsg-lib: don't free job in bsg_prepare_job"
- locking/lockdep: Add nest_lock integrity test
- watchdog: kempld: fix gcc-4.3 build
- irqchip/crossbar: Fix incorrect type of local variables
- mac80211_hwsim: check HWSIM_ATTR_RADIO_NAME length
- mac80211: fix power saving clients handling in iwlwifi
- net/mlx4_en: fix overflow in mlx4_en_init_timestamp()
- netfilter: nf_ct_expect: Change __nf_ct_expect_check() return value.
- iio: adc: xilinx: Fix error handling
- Btrfs: send, fix failure to rename top level inode due to name collision
- f2fs: do not wait for writeback in write_begin
- md/linear: shutup lockdep warnning
- sparc64: Migrate hvcons irq to panicked cpu
- net/mlx4_core: Fix VF overwrite of module param which disables DMFS on new
  probed PFs
- crypto: xts - Add ECB dependency
- ocfs2/dlmglue: prepare tracking logic to avoid recursive cluster lock
- slub: do not merge cache if slub_debug contains a never-merge flag
- scsi: scsi_dh_emc: return success in clariion_std_inquiry()
- net: mvpp2: release reference to txq_cpu[] entry after unmapping
- 

[Kernel-packages] [Bug 1730596] Re: s390/mm: fix write access check in gup_huge_pmd()

[Launchpad Bug Tracker]

This bug was fixed in the package linux - 4.10.0-40.44

---
linux (4.10.0-40.44) zesty; urgency=low

  * linux: 4.10.0-40.44 -proposed tracker (LP: #1731269)

  * s390/mm: fix write access check in gup_huge_pmd() (LP: #1730596)
- s390/mm: fix write access check in gup_huge_pmd()

 -- Kleber Sacilotto de Souza   Thu, 09 Nov
2017 15:24:07 +0100

** Changed in: linux (Ubuntu Zesty)
   Status: Fix Committed => Fix Released

-- 
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:
  Fix Committed
Status in linux package in Ubuntu:
  Fix Committed
Status in linux source package in Xenial:
  Fix Committed
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 
  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

[Kernel-packages] [Bug 1730596] Re: s390/mm: fix write access check in gup_huge_pmd()

[Frank Heimes]

** Tags removed: verification-needed-xenial
** Tags added: verification-done-xenial

-- 
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:
  Fix Committed
Status in linux package in Ubuntu:
  Fix Committed
Status in linux source package in Xenial:
  Fix Committed
Status in linux source package in Zesty:
  Fix Committed
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 
  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

[Kernel-packages] [Bug 1730596] Re: s390/mm: fix write access check in gup_huge_pmd()

[Kleber Sacilotto de Souza]

This bug is awaiting verification that the kernel in -proposed solves
the problem. Please test the kernel and update this bug with the
results. If the problem is solved, change the tag 'verification-needed-
xenial' to 'verification-done-xenial'. If the problem still exists,
change the tag 'verification-needed-xenial' to 'verification-failed-
xenial'.

If verification is not done by 5 working days from today, this fix will
be dropped from the source code, and this bug will be closed.

See https://wiki.ubuntu.com/Testing/EnableProposed for documentation how
to enable and use -proposed. Thank you!


** Tags added: verification-needed-xenial

-- 
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:
  Fix Committed
Status in linux package in Ubuntu:
  Fix Committed
Status in linux source package in Xenial:
  Fix Committed
Status in linux source package in Zesty:
  Fix Committed
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 
  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

[Kernel-packages] [Bug 1730596] Re: s390/mm: fix write access check in gup_huge_pmd()

[Frank Heimes]

** Tags removed: verification-needed-zesty
** Tags added: verification-done-zesty

-- 
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:
  Fix Committed
Status in linux package in Ubuntu:
  Fix Committed
Status in linux source package in Xenial:
  Fix Committed
Status in linux source package in Zesty:
  Fix Committed
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 
  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

[Kernel-packages] [Bug 1730596] Re: s390/mm: fix write access check in gup_huge_pmd()

[Kleber Sacilotto de Souza]

This bug is awaiting verification that the kernel in -proposed solves
the problem. Please test the kernel and update this bug with the
results. If the problem is solved, change the tag 'verification-needed-
zesty' to 'verification-done-zesty'. If the problem still exists, change
the tag 'verification-needed-zesty' to 'verification-failed-zesty'.

If verification is not done by 5 working days from today, this fix will
be dropped from the source code, and this bug will be closed.

See https://wiki.ubuntu.com/Testing/EnableProposed for documentation how
to enable and use -proposed. Thank you!


** Tags added: verification-needed-zesty

-- 
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:
  Fix Committed
Status in linux package in Ubuntu:
  Fix Committed
Status in linux source package in Xenial:
  Fix Committed
Status in linux source package in Zesty:
  Fix Committed
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 
  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

[Kernel-packages] [Bug 1730596] Re: s390/mm: fix write access check in gup_huge_pmd()

[Frank Heimes]

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

-- 
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:
  Fix Committed
Status in linux package in Ubuntu:
  Fix Committed
Status in linux source package in Xenial:
  Fix Committed
Status in linux source package in Zesty:
  Fix Committed
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 
  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

[Kernel-packages] [Bug 1730596] Re: s390/mm: fix write access check in gup_huge_pmd()

[Thadeu Lima de Souza Cascardo]

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

-- 
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:
  Fix Committed
Status in linux source package in Zesty:
  Fix Committed
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 
  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

[Kernel-packages] [Bug 1730596] Re: s390/mm: fix write access check in gup_huge_pmd()

[Kleber Sacilotto de Souza]

** Changed in: linux (Ubuntu Zesty)
   Status: In Progress => Fix Committed

-- 
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:
  Fix Committed
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 
  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

[Kernel-packages] [Bug 1730596] Re: s390/mm: fix write access check in gup_huge_pmd()

[Joseph Salisbury]

** 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 
+ 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 
  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 

[Kernel-packages] [Bug 1730596] Re: s390/mm: fix write access check in gup_huge_pmd()

[Frank Heimes]

** Changed in: ubuntu-z-systems
   Status: Triaged => In Progress

-- 
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:
  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.

  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

[Kernel-packages] [Bug 1730596] Re: s390/mm: fix write access check in gup_huge_pmd()

[Joseph Salisbury]

This commit is already in Artful and Bionic master-next, so testing of
Xenial and Zesty is the most important.

** Changed in: linux (Ubuntu Bionic)
   Status: In Progress => Fix Committed

** Changed in: linux (Ubuntu Artful)
   Status: In Progress => Fix Committed

-- 
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:
  Triaged
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:
  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.

  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

[Kernel-packages] [Bug 1730596] Re: s390/mm: fix write access check in gup_huge_pmd()

[Joseph Salisbury]

I built Xenial, Zesty and Artful test kernels with commit
ba385c0594e723d.  The test kernels can be downloaded from:


http://kernel.ubuntu.com/~jsalisbury/lp1730596/

Can you test these kernels to see if they resolve this bug?  If they do,
I'll submit an SRU request.

** Also affects: linux (Ubuntu Zesty)
   Importance: Undecided
   Status: New

** Also affects: linux (Ubuntu Bionic)
   Importance: Critical
 Assignee: Skipper Bug Screeners (skipper-screen-team)
   Status: Triaged

** Also affects: linux (Ubuntu Xenial)
   Importance: Undecided
   Status: New

** Also affects: linux (Ubuntu Artful)
   Importance: Undecided
   Status: New

** Changed in: linux (Ubuntu Xenial)
   Status: New => In Progress

** Changed in: linux (Ubuntu Zesty)
   Status: New => In Progress

** Changed in: linux (Ubuntu Artful)
   Status: New => In Progress

** Changed in: linux (Ubuntu Bionic)
   Status: Triaged => In Progress

** Changed in: linux (Ubuntu Xenial)
   Importance: Undecided => Critical

** Changed in: linux (Ubuntu Zesty)
   Importance: Undecided => Critical

** Changed in: linux (Ubuntu Artful)
   Importance: Undecided => Critical

** Changed in: linux (Ubuntu Bionic)
 Assignee: Skipper Bug Screeners (skipper-screen-team) => Joseph Salisbury 
(jsalisbury)

** Changed in: linux (Ubuntu Artful)
 Assignee: (unassigned) => Joseph Salisbury (jsalisbury)

** Changed in: linux (Ubuntu Zesty)
 Assignee: (unassigned) => Joseph Salisbury (jsalisbury)

** Changed in: linux (Ubuntu Xenial)
 Assignee: (unassigned) => Joseph Salisbury (jsalisbury)

-- 
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:
  Triaged
Status in linux package in Ubuntu:
  In Progress
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:
  In Progress
Status in linux source package in Bionic:
  In Progress

Bug description:
  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.

  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

[Kernel-packages] [Bug 1730596] Re: s390/mm: fix write access check in gup_huge_pmd()

[Frank Heimes]

** Changed in: ubuntu-z-systems
   Status: New => Triaged

-- 
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:
  Triaged
Status in linux package in Ubuntu:
  Triaged

Bug description:
  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.

  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

[Kernel-packages] [Bug 1730596] Re: s390/mm: fix write access check in gup_huge_pmd()

[Joseph Salisbury]

** Changed in: linux (Ubuntu)
   Importance: Undecided => Critical

** Changed in: linux (Ubuntu)
   Status: New => Triaged

** Tags removed: kernel-da-key
** Tags added: kernel-key

-- 
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:
  New
Status in linux package in Ubuntu:
  Triaged

Bug description:
  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.

  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

[Kernel-packages] [Bug 1730596] Re: s390/mm: fix write access check in gup_huge_pmd()

[Frank Heimes]

raising the importance to critical (after discussing with IBM)

** Changed in: ubuntu-z-systems
   Importance: High => Critical

-- 
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:
  New
Status in linux package in Ubuntu:
  New

Bug description:
  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.

  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

[Kernel-packages] [Bug 1730596] Re: s390/mm: fix write access check in gup_huge_pmd()

[Joseph Salisbury]

** Tags added: kernel-da-key

-- 
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:
  New
Status in linux package in Ubuntu:
  New

Bug description:
  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.

  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

[Kernel-packages] [Bug 1730596] Re: s390/mm: fix write access check in gup_huge_pmd()

[Frank Heimes]

** Also affects: ubuntu-z-systems
   Importance: Undecided
   Status: New

** Changed in: ubuntu-z-systems
   Importance: Undecided => High

** Changed in: ubuntu-z-systems
 Assignee: (unassigned) => Canonical Kernel Team (canonical-kernel-team)

-- 
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:
  New
Status in linux package in Ubuntu:
  New

Bug description:
  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.

  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