[Kernel-packages] [Bug 1302605] Re: Calls to /libx32/ld-linux-x32.so.2 hang when using auditd
*** This bug is a duplicate of bug 1325941 *** https://bugs.launchpad.net/bugs/1325941 ** Information type changed from Public to Public Security ** Tags added: amd64 testcase ** CVE removed: http://www.cve.mitre.org/cgi- bin/cvename.cgi?name=2014-3917 ** This bug has been marked a duplicate of bug 1325941 CVE-2014-3917 -- 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: Fix Released Status in linux source package in Trusty: Fix Committed 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 -- Mailing list: https://launchpad.net/~kernel-packages Post to : kernel-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~kernel-packages More help : https://help.launchpad.net/ListHelp
[Kernel-packages] [Bug 1302605] Re: Calls to /libx32/ld-linux-x32.so.2 hang when using auditd
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 -- Mailing list: https://launchpad.net/~kernel-packages Post to : kernel-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~kernel-packages More help : https://help.launchpad.net/ListHelp
[Kernel-packages] [Bug 1302605] Re: Calls to /libx32/ld-linux-x32.so.2 hang when using auditd
** Tags added: ua -- 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: 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 -- Mailing list: https://launchpad.net/~kernel-packages Post to : kernel-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~kernel-packages More help : https://help.launchpad.net/ListHelp
[Kernel-packages] [Bug 1302605] Re: Calls to /libx32/ld-linux-x32.so.2 hang when using auditd
The following commit landed upstream that at least intends to fix the bug outlined here, even though it does not enable proper auditing for x32. commit a3c54931199565930d6d84f4c3456f6440aefd41 Author: Andy Lutomirski l...@amacapital.net Date: Wed May 28 23:09:58 2014 -0400 auditsc: audit_krule mask accesses need bounds checking Fixes an easy DoS and possible information disclosure. This does nothing about the broken state of x32 auditing. eparis: If the admin has enabled auditd and has specifically loaded audit rules. This bug has been around since before git. Wow... Cc: sta...@vger.kernel.org Signed-off-by: Andy Lutomirski l...@amacapital.net Signed-off-by: Eric Paris epa...@redhat.com Signed-off-by: Linus Torvalds torva...@linux-foundation.org -- 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: 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 -- Mailing list: https://launchpad.net/~kernel-packages Post to : kernel-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~kernel-packages More help : https://help.launchpad.net/ListHelp
[Kernel-packages] [Bug 1302605] Re: Calls to /libx32/ld-linux-x32.so.2 hang when using auditd
CVE-2014-3917 has been assigned to this issue: http://seclists.org/oss- sec/2014/q2/377 Another proposed patch for this has been posted here: http://article.gmane.org/gmane.linux.kernel/1713179 — This one adds a guard around the array access but also drops syscall auditing for x32 calls. ** CVE added: http://www.cve.mitre.org/cgi- bin/cvename.cgi?name=2014-3917 -- 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: 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 -- Mailing list: https://launchpad.net/~kernel-packages Post to : kernel-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~kernel-packages More help : https://help.launchpad.net/ListHelp
[Kernel-packages] [Bug 1302605] Re: Calls to /libx32/ld-linux-x32.so.2 hang when using auditd
It seems that my patch was applied in the wrong place. You put it after the 4th arg instead of after %rsi is written (easy to miss given the vastly different assembly argument orders). We actually need to fix up %rsi / 2nd arg syscall number and instead it is now overwritten by the movq %rax,%rsi later. So this test kernel does not fix the issue. -- 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: 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 -- Mailing list: https://launchpad.net/~kernel-packages Post to : kernel-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~kernel-packages More help : https://help.launchpad.net/ListHelp
[Kernel-packages] [Bug 1302605] Re: Calls to /libx32/ld-linux-x32.so.2 hang when using auditd
Yeah, that brown paper bag was my fault. Thanks Launchpad for white- space dammaging the patch so I hand applied it in the wrong place. Bah. New kernels for test, with an updated patch included. If you could test and report. Thanks. -- 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: 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 -- Mailing list: https://launchpad.net/~kernel-packages Post to : kernel-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~kernel-packages More help : https://help.launchpad.net/ListHelp
[Kernel-packages] [Bug 1302605] Re: Calls to /libx32/ld-linux-x32.so.2 hang when using auditd
Sadly we need a second patch, after which it runs stable in my testing.
I'm not into the intrinsic details of x32, but apparently the syscalls
come in through both the 64bit and 32bit paths, which I find a bit
weird. (At least my first patch made it occur significantly less often.)
Patch attached this time. IS_IA32 is defined like this:
#elif defined CONFIG_IA32_EMULATION
# define IS_IA32is_compat_task()
process_64.c says this about is_compat_task():
/* is_compat_task() uses the presence of the x32
syscall bit flag to determine compat status */
And indeed:
static inline bool is_compat_task(void)
{
return is_ia32_task() || is_x32_task();
}
** Patch added: ptrace.diff
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1302605/+attachment/4120171/+files/ptrace.diff
--
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:
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
--
Mailing list: https://launchpad.net/~kernel-packages
Post to : kernel-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kernel-packages
More help : https://help.launchpad.net/ListHelp
[Kernel-packages] [Bug 1302605] Re: Calls to /libx32/ld-linux-x32.so.2 hang when using auditd
** Tags added: 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: 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 -- Mailing list: https://launchpad.net/~kernel-packages Post to : kernel-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~kernel-packages More help : https://help.launchpad.net/ListHelp
[Kernel-packages] [Bug 1302605] Re: Calls to /libx32/ld-linux-x32.so.2 hang when using auditd
** Package changed: eglibc (Ubuntu) = linux (Ubuntu) ** Also affects: linux (Ubuntu Trusty) Importance: Undecided Status: New -- 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: 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 -- Mailing list: https://launchpad.net/~kernel-packages Post to : kernel-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~kernel-packages More help : https://help.launchpad.net/ListHelp
[Kernel-packages] [Bug 1302605] Re: Calls to /libx32/ld-linux-x32.so.2 hang when using auditd
Ok I have applied the patch as proposed to a test kernel. Could you test the kernels at the URL below and confirm they do fix things for you: http://people.canonical.com/~apw/lp1302605-trusty/ Please report any testing back here. -- 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: 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 -- Mailing list: https://launchpad.net/~kernel-packages Post to : kernel-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~kernel-packages More help : https://help.launchpad.net/ListHelp
