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

  * 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 <>  Thu, 15 Mar 2018 15:08:03

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

** CVE added:

** CVE added:

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

** CVE added:

** CVE added:

** CVE added:

** CVE added:

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

  bnx2x_attn_int_deasserted3:4323 MC assert!

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

Bug description:
  SRU Justification

  A ppc64le system runs as a guest under PowerVM. This guest has a bnx2x
  card attached, and uses openvswitch to bridge an ibmveth interface for
  traffic from other LPARs.

  We see the following crash sometimes when running netperf:
  May 10 17:16:32 tuk6r1phn2 kernel: bnx2x: 
[bnx2x_attn_int_deasserted3:4323(enP24p1s0f2)]MC assert!
  May 10 17:16:32 tuk6r1phn2 kernel: bnx2x: 
[bnx2x_mc_assert:720(enP24p1s0f2)]XSTORM_ASSERT_LIST_INDEX 0x2
  May 10 17:16:32 tuk6r1phn2 kernel: bnx2x: 
[bnx2x_mc_assert:736(enP24p1s0f2)]XSTORM_ASSERT_INDEX 0x0 = 0x00000000 
0x25e42a7e 0x00462a38 0x00010052
  May 10 17:16:32 tuk6r1phn2 kernel: bnx2x: 
[bnx2x_mc_assert:750(enP24p1s0f2)]Chip Revision: everest3, FW Version: 7_13_1
  May 10 17:16:32 tuk6r1phn2 kernel: bnx2x: 
[bnx2x_attn_int_deasserted3:4329(enP24p1s0f2)]driver assert
  May 10 17:16:32 tuk6r1phn2 kernel: bnx2x: 
[bnx2x_panic_dump:923(enP24p1s0f2)]begin crash dump -----------------
  ... (dump of registers follows) ...

  Subsequent debugging reveals that the packets causing the issue come
  through the ibmveth interface - from the AIX LPAR. The veth protocol
  is 'special' - communication between LPARs on the same chassis can use
  very large (64k) frames to reduce overhead. Normal networks cannot
  handle such large packets, so traditionally, the VIOS partition would
  signal to the AIX partitions that it was 'special', and AIX would send
  regular, ethernet-sized packets to VIOS, which VIOS would then send

  This signalling between VIOS and AIX is done in a way that is not
  standards-compliant, and so was never made part of Linux. Instead, the
  Linux driver has always understood large frames and passed them up the
  network stack.

  In some cases (e.g. with TCP), multiple TCP segments are coalesced
  into one large packet. In Linux, this goes through the generic receive
  offload code, using a similar mechanism to GSO. These segments can be
  very large which presents as a very large MSS (maximum segment size)
  or gso_size.

  Normally, the large packet is simply passed to whatever network
  application on Linux is going to consume it, and everything is OK.

  However, in this case, the packets go through Open vSwitch, and are
  then passed to the bnx2x driver. The bnx2x driver/hardware supports
  TSO and GSO, but with a restriction: the maximum segment size is
  limited to around 9700 bytes. Normally this is more than adequate.
  However, if a large packet with very large (>9700 byte) TCP segments
  arrives through ibmveth, and is passed to bnx2x, the hardware will


  bnx2x card panics, requiring power cycle to restore functionality.

  The workaround is turning off TSO, which prevents the crash as the
  kernel resegments *all* packets in software, not just ones that are
  too big. This has a performance cost.


  Test packet size in bnx2x feature check path and disable GSO if it is
  too large. To do this we move a function from one file to another and
  add another in the networking core.

  [Regression Potential]

  A/B/X: The changes to the network core are easily reviewed. The changes to 
behaviour are limited to the bnx2x card driver.
  The most likely failure case is a false-positive on the size check, which 
would lead to a performance regression only.

  T: This also involves a different change to the networking core to add
  the old-style GSO checking, which is more invasive. However the
  changes are simple and easily reviewed.

To manage notifications about this bug go to:

Mailing list:
Post to     :
Unsubscribe :
More help   :

Reply via email to