[Bug 1302605] Re: Calls to /libx32/ld-linux-x32.so.2 hang

[Margarita Manterola]

The problem is related to auditd, so you need to have audit rules
installed, and sometimes you need to restart auditd to get this to
happen.

I reproduced this in a vanilla trusty install by doing the following steps:
 1) Install gcc-multilib (brings in a lot of x32 stuff, just libc6-x32 was not enough)
 2) Add some auditd rules.  Apparently which rules you add are not relevant, as long as you add some of them.  I'll add an example that might trigger it.
 3) while true; do sudo /etc/init.d/auditd stop && sudo /etc/init.d/auditd start && ldd /bin/busybox; done

it might take a few tries, but the while should hang.

Example rules to add. As I said, which rules you add, it's irrelevant,
just some rules are needed:

-a exit,always -F arch=b64 -S open -F dir=/home -F euid!=0 -F a1&2 -F success=1 -C euid!=obj_uid -k permissive_write
-a exit,always -F arch=b64 -S open -F dir=/home -F euid!=0 -F a1&1 -F success=1 -C euid!=obj_uid -k permissive_write
-a exit,always -F arch=b64 -S socket -F success=1 -F a0!=0 -F a0!=1 -F a0!=2 -F a0!=10 -F a0!=16 -F a0!=17 -k funky_socket

When the call hangs, there are two kernel call traces in dmesg. I'll
attach the content to this comment.

The faulty function is audit_filter_syscall, and it seems to be related
to some data being wrongly sized. More info likely to follow.

** Attachment added: "Call trace in dmesg (including removal of audit rules)"
   https://bugs.launchpad.net/ubuntu/+source/eglibc/+bug/1302605/+attachment/4118289/+files/call-traces-in-dmesg.txt

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

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

Status in “eglibc” package in Ubuntu:
  Confirmed

Bug 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/eglibc/+bug/1302605/+subscriptions