[Bug 1532789] Update Released

[Martin Pitt]

The verification of the Stable Release Update for multipath-tools has
completed successfully and the package has now been released to
-updates.  Subsequently, the Ubuntu Stable Release Updates Team is being
unsubscribed and will not receive messages about this bug report.  In
the event that you encounter a regression using the package from
-updates please report a new bug using ubuntu-bug and tag the bug report
regression-update so we can easily find any regressions.

-- 
You received this bug notification because you are a member of Ubuntu
Foundations Bugs, which is subscribed to multipath-tools in Ubuntu.
https://bugs.launchpad.net/bugs/1532789

Title:
  Trusty multipath-tools suffering seg faults

Status in multipath-tools package in Ubuntu:
  Invalid
Status in multipath-tools source package in Trusty:
  Fix Released

Bug description:
  [Impact]

   * multipath segfaults constantly on given circumstances
   * multipath might make other tools relying on it to misbehave (openstack)

  [Test Case]

   * Core Dump given. No test case or reproducer. 
   * Will ask user in charge for the dump to verify fix.

  [Regression Potential]
   
   * Cherry-picked commit that EXACTLY fits seg fault and dump analysis.
   * Minor change.

  [Other Info]

  ####

  Original BUG Description:

  It was brought to my knowledge that multipath-tools is facing
  segfaults:

  ----
  Core was generated by `/sbin/multipath -v0 /dev/sdab'. Program terminated with signal 11, Segmentation fault. #0  0x00007f2b5f6c8e88 in scsi_sysfs_pathinfo (pp=0xe5c0e0) at discovery.c:441
  ----

  All core dumps I received - several - have IP at the same place:

  ----
  #0  0x00007f2b5f6c8e88 in scsi_sysfs_pathinfo (pp=0xe5c0e0) at discovery.c:441
  #1  0x00007f2b5f6c9c26 in sysfs_pathinfo (pp=0xe5c0e0) at discovery.c:689
  #2  0x00007f2b5f6ca48b in pathinfo (pp=0xe5c0e0, hwtable=0xe222f0, mask=63) at discovery.c:823
  #3  0x00007f2b5f6c7858 in store_pathinfo (pathvec=0xe2d8d0, hwtable=0xe222f0, udevice=0xe5bc60, flag=31, pp_ptr=0x0) at discovery.c:57
  #4  0x00007f2b5f6c7953 in path_discover (pathvec=0xe2d8d0, conf=0xe22110, udevice=0xe5bc60, flag=31) at discovery.c:91
  #5  0x00007f2b5f6c7ad3 in path_discovery (pathvec=0xe2d8d0, conf=0xe22110, flag=31) at discovery.c:127
  #6  0x00000000004025e6 in configure () at main.c:322
  ----

  From libmultipath/discovery.c:

  if (!strncmp(udev_device_get_subsystem(parent), "scsi", 4)) {

  It is clear that strncmp is not taking care of cases when
  udev_device_get_subsystem returns NULL and that is - most likely -
  what is happening here. I have checked upstream development for this
  particular fix and found the following commit:

  ----
  commit e546687e046b1eb1cbe5567e9d7850cbbd682dba
  Author: Benjamin Marzinski <bmarzins at redhat.com>
  Date:   Sat Jan 12 00:04:54 2013 -0600

      multipath: check for NULL from udev_device_get_*

      The udev_device_get_* functions can return NULL, an occassionally do
      so in the multipathd code.  multipath needs to check if the result
      is NULL before dereferencing it.

      Signed-off-by: Benjamin Marzinski <bmarzins at redhat.com>
  ----

  Takes care of exactly this situation. This commit is found in the
  following versions:

  ----
  inaddy at rafael(/home/inaddy/Codes/bugs/1532789/upstream/multipath-tools)$ git tag --contains e546687e046b1eb1cbe5567e9d7850cbbd682dba
  0.5.0
  ----

  And, from rmadison, this fix should be backported to Trusty & Vivid
  (not at 0.5.0 yet).

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/multipath-tools/+bug/1532789/+subscriptions