init: symbol lookup error: /lib/powerpc64le-linux-gnu/libnss_ldap.so.2: undefined symbol: __libc_lock_lock
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
libnss-ldap (Debian) |
Fix Released
|
Unknown
|
|||
libnss-ldap (Ubuntu) |
Fix Released
|
Critical
|
Unassigned | ||
Precise |
Invalid
|
Critical
|
Unassigned | ||
Trusty |
Fix Released
|
Critical
|
Louis Bouchard | ||
Utopic |
Fix Released
|
Critical
|
Louis Bouchard |
Bug Description
[SRU justification]
The version of the library in the archive for Utopic and Trusty has been built prior to a change in glibc that removes an expected symbol. Rebuild of the libnss-ldap library with the current source package will render the library unusable and may cause systems to become unbootable.
[Impact]
Without this fix, a rebuild of the libnss-ldap package will cause grave impact where usage of the libnss-ldap will segfault. Such a segfault during the boot process will cause the system to become unbootable.
[Fix]
Backport the glibc-2.16.patch that is now merged in Vivid into Utopic and Trusty. The version of the library in Precise already uses the correct glibc symbol.
[Test Case]
On a server properly configured for ldap authentication :
root@trusty-
john:x:
The same test on arm64 or ppc64el platform where the libnss-ldap have been rebuilt recently you will get :
root@trusty-
Segmentation fault (core dumped)
$ sudo apt-get download libnss-ldap
$ mkdir tmp
$ dpkg -x libnss-
$ nm -D tmp/lib/
w __pthread_
w __pthread_
#Rebuild the library
$ pull-lp-source libnss-ldap trusty
$ sbuild -A -d trusty libnss-
$ rm -Rf tmp/*
$ dpkg -x libnss-
$ nm -D tmp/lib/
U __libc_lock_lock
U __libc_lock_unlock
Notice that the libnss-ldap version change (2.15 -> 2.19). With the newly built version, the expected _pthread_
[Regression]
None expected. This is already present and in use in the upstream version of the library.
15:27 <rbasak> caribou: so what I don't like about this is that the patch seems a bit invasive in an area where if there's a regression, it'll be in multithreading code that'll be non-deterministic and thus difficult to test.
15:27 <rbasak> caribou: OTOH, it's broken on ppc64el at the moment? That means we need to fix it.
15:28 <rbasak> Having an active upstream that had committed the code would give me more confidence that the patch is good (since they're more familiar with the code and will have reviewed it)
15:29 <rbasak> But Debian have committed it, so that's better than nothing.
15:31 <rbasak> caribou: I think we have no choice but to push it to Trusty (and Utopic), but we should let the SRU team decide at that stage. IMHO, my concern should be noted in "Regression Potential", so I'll do that now.
[Original Description of the problem]
Unlike previously thought, this bug is _NOT_ specific to the PPC64EL architecture. More details in the analysis.
Many commands that require the use of libnss-ldap will fail with Segmentation Fault. The boot procedure itself can be blocked with the following message.
One potential workaround is to remove the use of ldap from the /etc/nsswitch.conf file to at least provide a bootable system.
Changed in libnss-ldap (Ubuntu): | |
status: | New → Confirmed |
importance: | Undecided → Critical |
Changed in libnss-ldap (Ubuntu Utopic): | |
status: | New → Confirmed |
importance: | Undecided → Critical |
description: | updated |
Changed in libnss-ldap (Ubuntu): | |
assignee: | nobody → Louis Bouchard (louis-bouchard) |
Changed in libnss-ldap (Ubuntu Utopic): | |
assignee: | nobody → Louis Bouchard (louis-bouchard) |
Changed in libnss-ldap (Ubuntu): | |
status: | Confirmed → In Progress |
description: | updated |
description: | updated |
Changed in libnss-ldap (Debian): | |
status: | Unknown → Fix Released |
Analysis
========
Upon boot of a ppc64el system configured to authenticate as an LDAP client, the boot process is interrupted with :
/sbin/init: symbol lookup error: /lib/powerpc64l e-linux- gnu/libnss_ ldap.so. 2: undefined symbol: __libc_lock_lock
Apparently __libc_lock_lock is missing from the libnss_ldap.so library.
Looking at the symbols exported by the library on PPC64el we see :
- For libnss_ldap : e-linux- gnu/libnss_ ldap.so. 2 | grep _lock
$ nm -D /lib/powerpc64l
U __libc_lock_lock
U __libc_lock_unlock
• For libc : e-linux- gnu/libc- 2.19.so | grep _lock
$ nm -D /lib/powerpc64l
000000000008f4a0 T _IO_list_lock
0000000000088a70 T _IO_peekc_locked
00000000001313b0 T pthread_mutex_lock
The same command on AMD64 returns : 64-linux- gnu/libnss_ ldap.so. 2 | grep lock mutex_lock mutex_unlock 64-linux- gnu/libc- 2.19.so | grep _lock
- For libnss_ldap:
# nm -D /lib/x86_
w __pthread_
w __pthread_
• For libc :
# nm -D /lib/x86_
...
0000000000108270 T pthread_mutex_lock
So the symbol is _not_ exported by the libc on ppc64el even though libnss_ldap is expecting to find it.
This lock is only used once in libnss_ldap :
static int HAVE_LIBC_ LOCK_H) || defined( HAVE_BITS_ LIBC_LOCK_ H) LIBC_LOCK_ H */
ltf_mutex_lock (void *mutexp)
{
#if defined(
return __libc_lock_lock (*(pthread_mutex_t *) mutexp);
#elif defined(HPUX)
return __thread_mutex_lock ((pthread_mutex_t *) mutexp);
#else
# ifdef _AIX
if (__multi_threaded == 0)
return 0;
# endif
return pthread_mutex_lock ((pthread_mutex_t *) mutexp);
#endif /* HAVE_LIBC_LOCK_H || HAVE_BITS_
}
So apparently, the HAVE_LIBC_LOCK_H symbol is defined on ppc64el, or at least appear to be even if the libc does not export that libc_lock_lock symbol.