This bug was fixed in the package linux - 3.13.0-144.193

---------------
linux (3.13.0-144.193) trusty; urgency=medium

  * linux: 3.13.0-144.193 -proposed tracker (LP: #1755227)

  * CVE-2017-12762
    - isdn/i4l: fix buffer overflow

  * CVE-2017-17807
    - KEYS: add missing permission check for request_key() destination

  * bnx2x_attn_int_deasserted3:4323 MC assert! (LP: #1715519) //
    CVE-2018-1000026
    - net: Add ndo_gso_check
    - net: create skb_gso_validate_mac_len()
    - bnx2x: disable GSO where gso_size is too big for hardware

  * CVE-2017-17448
    - netfilter: nfnetlink_cthelper: Add missing permission checks

  * CVE-2017-11089
    - cfg80211: Define nla_policy for NL80211_ATTR_LOCAL_MESH_POWER_MODE

  * CVE-2018-5332
    - RDS: Heap OOB write in rds_message_alloc_sgs()

  * ppc64el: Do not call ibm,os-term on panic (LP: #1736954)
    - powerpc: Do not call ppc_md.panic in fadump panic notifier

  * CVE-2017-17805
    - crypto: salsa20 - fix blkcipher_walk API usage

  * [Hyper-V] storvsc: do not assume SG list is continuous when doing bounce
    buffers (LP: #1742480)
    - SAUCE: storvsc: do not assume SG list is continuous when doing bounce
      buffers

  * Shutdown hang on 16.04 with iscsi targets (LP: #1569925)
    - scsi: libiscsi: Allow sd_shutdown on bad transport

  * CVE-2017-17741
    - KVM: Fix stack-out-of-bounds read in write_mmio

  * CVE-2017-5715 (Spectre v2 Intel)
    - [Packaging] pull in retpoline files

 -- Stefan Bader <stefan.ba...@canonical.com>  Thu, 15 Mar 2018 15:08:03
+0100

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

** CVE added: https://cve.mitre.org/cgi-bin/cvename.cgi?name=2017-11089

** CVE added: https://cve.mitre.org/cgi-bin/cvename.cgi?name=2017-12762

** CVE added: https://cve.mitre.org/cgi-bin/cvename.cgi?name=2017-5715

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

** CVE added: https://cve.mitre.org/cgi-bin/cvename.cgi?name=2017-16995

** CVE added: https://cve.mitre.org/cgi-bin/cvename.cgi?name=2017-17862

** CVE added: https://cve.mitre.org/cgi-bin/cvename.cgi?name=2017-5753

** CVE added: https://cve.mitre.org/cgi-bin/cvename.cgi?name=2018-8043

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

Title:
  ppc64el: Do not call ibm,os-term on panic

Status in linux package in Ubuntu:
  Fix Released
Status in linux source package in Trusty:
  Fix Released
Status in linux source package in Xenial:
  Fix Released
Status in linux source package in Artful:
  Fix Released
Status in linux source package in Bionic:
  Fix Released

Bug description:
  [Impact]
  When panic_timeout is set, the user would expect the system to reboot. 
However, it is shutdown, possibly requiring user intervention to power on the 
system again. This may impact availability. This happens under certain versions 
of qemu (2.10+) emulating pseries.

  [Test Case]
  Built kernels (trusty, xenial, zesty, artful) have been tested and they 
reboot after the fix, when running under an affected qemu.

  [Regression Potential]
  fadump might require that RTAS ibm,os-term be called. The fix should still 
allow it to be called when fadump is registered.

  
  -----------

  When panic_timeout is set, the user would expect that the system would
  reboot after some timeout after a panic.

  However, on powerpc architecture, a panic notifier may not ever return
  and even shutdown the system. The main example that impacts platforms
  we support is pseries calling RTAS ibm,os-term.

  That panic notifier and calling RTAS ibm,os-term is useful for fadump,
  so this should not be impacted.

  The Linux code has changed back and forth on considering the
  panic_timeout setting and checking whether ibm,extended-os-term was
  available. Unfortunately, recent changes on qemu led to the guest
  being shut down when calling ibm,os-term even when ibm,extended-os-
  term was available.

  Luckily, upstream Linux already has the change that does not call ibm
  ,os-term on panic, but only during fadump. So, we can use that commit
  for fixing this. Changing qemu itself is harder as: 1) qemu community
  already decided some qemu settings should override PAPR; 2) updating
  deployed hypervisor is harder than updating our guest kernels.

  Cascardo.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1736954/+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

Reply via email to