Calls to /libx32/ld-linux-x32.so.2 hang when using auditd
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
linux (Ubuntu) |
Fix Released
|
Undecided
|
Unassigned | ||
Trusty |
Fix Committed
|
Undecided
|
Unassigned |
Bug Description
SRU Justification:
Impact: Calls to /libx32/
Fix: Upstream, a3c549311995659
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/
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=
summary: |
- Calls to /libx32/ld-linux-x32.so.2 hang + Calls to /libx32/ld-linux-x32.so.2 hang when using auditd |
affects: | eglibc (Ubuntu) → linux (Ubuntu) |
tags: | added: patch |
tags: | added: ua |
Changed in linux (Ubuntu Trusty): | |
status: | New → Fix Committed |
Changed in linux (Ubuntu): | |
status: | Confirmed → Fix Released |
information type: | Public → Public Security |
tags: | added: amd64 testcase |
So, one extra comment. All affected machines that I've looked at till now, get fixed when rebooting into the -22 kernel, except one that is a virtual machine (using libvirt). That one is still broken even when running -22.