kernel-packages team mailing list archive

[Rafael David Tinoco <rafael.tinoco@xxxxxxxxxxxxx>]

Attaching patch that is being sent to Kernel Team by e-mail.

** Description changed:

+ SRU Justification:
+ 
+ Impact: Calls to /libx32/ld-linux-x32.so.2 hang when using auditd
+ Fix: Upstream, a3c54931199565930d6d84f4c3456f6440aefd41
+ Testcase: Comment #7
+ 
+ Old Description:
+ 
  I'm running trusty on a bunch of machines, doing frequent dist-upgrades.
  My hosts have gcc-multilib installed.
  
  Yesterday, I noticed that initramfs generation was hanging.  Today I
  investigated further and found out that what was hanging were the calls
  to /libx32/ld-linux-x32.so.2.
  
  This is triggered in initramfs generation because there are at some
  hooks that incorrectly use copy_exec to copy shell scripts into the
  initramfs image.  In a working machine, when ldd encounters a shell
  script, it will first call the 64bit linker and since it fails, it will
  then call the 32bit linker which will also fail.
  
  However, in a machine affected by this bug, the second call will hang
  forever, preventing new image generation, and package updates in
  general, when this happens as a trigger for update-initramfs.
  
  Originally I thought this was related to the kernel version, since I was
  unable to reproduce in a freshly installed machine running -22 and was
  reproducing it in a machine running -20, but now I'm also reproducing it
  in a machine running -22, so it must be something else.
  
  I'm sorry I can't provide the exact cause right now, but I think it's
  worth noting that in some situation there might be a problem, and try to
  find out which those situations are.
  
  I now have one host running 3.13.0-22-generic, with
  libc6-x32=2.19-0ubuntu3, where doing ldd /usr/bin/ldd hangs, and another
  host, with the exact same kernel and libc6-x32 version where doing ldd
  /usr/bin/ldd produces the expected error message (not a dynamic
  executable).  The main difference is that the first one was installed
  yesterday and the second one was installed today.  Both are dist-
  upgraded to the latest version of everything.

** Patch added: "0001-Trusty-CVE-2014-3917-upstream-auditsc-audit_krule-ma.patch"
   https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1302605/+attachment/4162138/+files/0001-Trusty-CVE-2014-3917-upstream-auditsc-audit_krule-ma.patch

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

Title:
  Calls to /libx32/ld-linux-x32.so.2 hang when using auditd

Status in “linux” package in Ubuntu:
  Confirmed
Status in “linux” source package in Trusty:
  New

Bug description:
  SRU Justification:

  Impact: Calls to /libx32/ld-linux-x32.so.2 hang when using auditd
  Fix: Upstream, a3c54931199565930d6d84f4c3456f6440aefd41
  Testcase: Comment #7

  Old Description:

  I'm running trusty on a bunch of machines, doing frequent dist-
  upgrades.  My hosts have gcc-multilib installed.

  Yesterday, I noticed that initramfs generation was hanging.  Today I
  investigated further and found out that what was hanging were the
  calls to /libx32/ld-linux-x32.so.2.

  This is triggered in initramfs generation because there are at some
  hooks that incorrectly use copy_exec to copy shell scripts into the
  initramfs image.  In a working machine, when ldd encounters a shell
  script, it will first call the 64bit linker and since it fails, it
  will then call the 32bit linker which will also fail.

  However, in a machine affected by this bug, the second call will hang
  forever, preventing new image generation, and package updates in
  general, when this happens as a trigger for update-initramfs.

  Originally I thought this was related to the kernel version, since I
  was unable to reproduce in a freshly installed machine running -22 and
  was reproducing it in a machine running -20, but now I'm also
  reproducing it in a machine running -22, so it must be something else.

  I'm sorry I can't provide the exact cause right now, but I think it's
  worth noting that in some situation there might be a problem, and try
  to find out which those situations are.

  I now have one host running 3.13.0-22-generic, with
  libc6-x32=2.19-0ubuntu3, where doing ldd /usr/bin/ldd hangs, and
  another host, with the exact same kernel and libc6-x32 version where
  doing ldd /usr/bin/ldd produces the expected error message (not a
  dynamic executable).  The main difference is that the first one was
  installed yesterday and the second one was installed today.  Both are
  dist-upgraded to the latest version of everything.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1302605/+subscriptions