| 2017-05-05 13:59:56 |
Suho Meso |
bug |
|
|
added bug |
| 2017-05-05 14:18:43 |
Ryan Tandy |
openldap (Ubuntu): assignee |
|
Ryan Tandy (rtandy) |
|
| 2017-05-05 14:24:29 |
Ryan Tandy |
attachment added |
|
0001-ITS-8648-add-back-mutex-for-sasl_client_init.patch https://bugs.launchpad.net/bugs/1688575/+attachment/4872308/+files/0001-ITS-8648-add-back-mutex-for-sasl_client_init.patch |
|
| 2017-05-05 16:23:07 |
Ubuntu Foundations Team Bug Bot |
tags |
|
patch |
|
| 2017-05-05 16:23:14 |
Ubuntu Foundations Team Bug Bot |
bug |
|
|
added subscriber Ubuntu Review Team |
| 2017-05-07 22:11:24 |
Ryan Tandy |
bug task added |
|
openldap |
|
| 2017-05-07 22:11:30 |
Ryan Tandy |
openldap (Ubuntu): status |
New |
Fix Committed |
|
| 2017-05-07 22:11:41 |
Ryan Tandy |
openldap (Ubuntu): status |
Fix Committed |
New |
|
| 2017-05-07 22:15:23 |
Ryan Tandy |
openldap: status |
New |
Fix Committed |
|
| 2017-05-09 02:22:04 |
Ryan Tandy |
openldap (Ubuntu): status |
New |
In Progress |
|
| 2017-05-19 08:02:59 |
Christian Ehrhardt |
bug |
|
|
added subscriber Ubuntu Server Team |
| 2017-07-18 13:26:58 |
Andreas Hasenack |
tags |
patch |
patch server-next |
|
| 2017-08-10 05:57:39 |
Launchpad Janitor |
openldap (Ubuntu): status |
In Progress |
Fix Released |
|
| 2017-08-11 19:32:13 |
Ryan Tandy |
openldap: status |
Fix Committed |
Fix Released |
|
| 2017-08-11 19:32:21 |
Ryan Tandy |
openldap (Ubuntu): assignee |
Ryan Tandy (rtandy) |
|
|
| 2018-05-14 14:34:22 |
Andreas Hasenack |
bug |
|
|
added subscriber Andreas Hasenack |
| 2018-05-15 06:03:39 |
Ryan Tandy |
attachment added |
|
Makefile https://bugs.launchpad.net/bugs/1688575/+attachment/5139678/+files/Makefile |
|
| 2018-05-15 06:03:39 |
Ryan Tandy |
attachment added |
|
sasltest.c https://bugs.launchpad.net/bugs/1688575/+attachment/5139679/+files/sasltest.c |
|
| 2018-05-15 06:03:39 |
Ryan Tandy |
attachment added |
|
testscript https://bugs.launchpad.net/bugs/1688575/+attachment/5139680/+files/testscript |
|
| 2018-05-15 06:33:22 |
Ryan Tandy |
attachment added |
|
openldap_2.4.42+dfsg-2ubuntu3.3.debdiff https://bugs.launchpad.net/bugs/1688575/+attachment/5139684/+files/openldap_2.4.42+dfsg-2ubuntu3.3.debdiff |
|
| 2018-05-15 21:13:40 |
Andreas Hasenack |
nominated for series |
|
Ubuntu Xenial |
|
| 2018-05-15 21:13:40 |
Andreas Hasenack |
bug task added |
|
openldap (Ubuntu Xenial) |
|
| 2018-05-15 21:13:47 |
Andreas Hasenack |
openldap (Ubuntu Xenial): assignee |
|
Andreas Hasenack (ahasenack) |
|
| 2018-05-15 21:13:57 |
Andreas Hasenack |
openldap (Ubuntu Xenial): status |
New |
Triaged |
|
| 2018-05-15 21:14:05 |
Andreas Hasenack |
openldap (Ubuntu Xenial): importance |
Undecided |
High |
|
| 2018-05-16 21:00:29 |
Andreas Hasenack |
description |
I have a slapd problem on a freshly installed 16.04 machine:
slapd[17107]: segfault at 1a ip 00007f3c12c79f55 sp 00007f3c03c2d080 error 4 in libsasl2.so.2.0.25[7f3c12c72000+19000]
I'm using the server as Slave LDAP-Server and sync replication with kerberos authentication.
The service either starts and runs successfully or it fails with segmentation fault or 100% CPU.
Maybe an useful info, I'm replicating two databases. When I deactivate syncrepl for one of them (doesn't matter which one) the problem is not occuring.
Linux xxx 4.4.0-75-generic #96-Ubuntu SMP Thu Apr 20 09:56:33 UTC 2017 x86_64 x86_64 x86_64 GNU/Linux
slapd 2.4.42+dfsg-2ubuntu3.1
libsasl2-2:amd64 2.1.26.dfsg1-14build1
libsasl2-modules:amd64 2.1.26.dfsg1-14build1
libsasl2-modules-gssapi-mit:amd64 2.1.26.dfsg1-14build1
GDB debug:
Starting program: /usr/sbin/slapd -h "ldap:/// ldaps:/// ldapi:///" -u openldap -g openldap -f /etc/ldap/slapd.conf -d 256
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
590c82ab @(#) $OpenLDAP: slapd (Ubuntu) (May 11 2016 16:12:05) $
buildd@lgw01-10:/build/openldap-mF7Kfq/openldap-2.4.42+dfsg/debian/build/servers/slapd
590c82ab slapd starting
[New Thread 0x7f2e96b7b700 (LWP 42139)]
[New Thread 0x7f2e9637a700 (LWP 42140)]
[New Thread 0x7f2e95b79700 (LWP 42141)]
[New Thread 0x7f2e95378700 (LWP 42142)]
[New Thread 0x7f2e94b77700 (LWP 42143)]
590c82ba slap_client_connect: URI=ldap://xxx ldap_sasl_interactive_bind_s failed (-6)
590c82ba do_syncrepl: rid=132 rc -6 retrying (9 retries left)
Thread 4 "slapd" received signal SIGSEGV, Segmentation fault.
[Switching to Thread 0x7f2e95b79700 (LWP 42141)]
0x00007f2ea53035b5 in sasl_client_add_plugin () from /usr/lib/x86_64-linux-gnu/libsasl2.so.2
(gdb) thr apply all bt
Thread 6 (Thread 0x7f2e94b77700 (LWP 42143)):
#0 pthread_cond_wait@@GLIBC_2.3.2 () at ../sysdeps/unix/sysv/linux/x86_64/pthread_cond_wait.S:185
#1 0x00007f2ea59463f3 in ?? () from /usr/lib/x86_64-linux-gnu/libldap_r-2.4.so.2
#2 0x00007f2ea487c6ba in start_thread (arg=0x7f2e94b77700) at pthread_create.c:333
#3 0x00007f2ea45b282d in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:109
Thread 5 (Thread 0x7f2e95378700 (LWP 42142)):
#0 pthread_cond_wait@@GLIBC_2.3.2 () at ../sysdeps/unix/sysv/linux/x86_64/pthread_cond_wait.S:185
#1 0x00007f2ea59463f3 in ?? () from /usr/lib/x86_64-linux-gnu/libldap_r-2.4.so.2
#2 0x00007f2ea487c6ba in start_thread (arg=0x7f2e95378700) at pthread_create.c:333
#3 0x00007f2ea45b282d in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:109
Thread 4 (Thread 0x7f2e95b79700 (LWP 42141)):
#0 0x00007f2ea53035b5 in sasl_client_add_plugin () from /usr/lib/x86_64-linux-gnu/libsasl2.so.2
#1 0x00007f2ea530f250 in ?? () from /usr/lib/x86_64-linux-gnu/libsasl2.so.2
#2 0x00007f2ea5303d69 in sasl_client_init () from /usr/lib/x86_64-linux-gnu/libsasl2.so.2
#3 0x00007f2ea594da6c in ldap_int_sasl_init () from /usr/lib/x86_64-linux-gnu/libldap_r-2.4.so.2
#4 0x00007f2ea594db2c in ldap_int_sasl_open () from /usr/lib/x86_64-linux-gnu/libldap_r-2.4.so.2
#5 0x00007f2ea594e2d4 in ldap_int_sasl_bind () from /usr/lib/x86_64-linux-gnu/libldap_r-2.4.so.2
#6 0x00007f2ea5951828 in ldap_sasl_interactive_bind () from /usr/lib/x86_64-linux-gnu/libldap_r-2.4.so.2
#7 0x00007f2ea5951a4e in ldap_sasl_interactive_bind_s () from /usr/lib/x86_64-linux-gnu/libldap_r-2.4.so.2
#8 0x0000561fbc556db4 in slap_client_connect (ldp=0x561fbe1e9f68, sb=0x561fbe1e9d40) at ../../../../servers/slapd/config.c:2063
#9 0x0000561fbc5c699d in do_syncrep1 (si=0x561fbe1e9d10, op=0x7f2e95b787b0) at ../../../../servers/slapd/syncrepl.c:618
#10 do_syncrepl (ctx=<optimized out>, arg=0x561fbe1e5620) at ../../../../servers/slapd/syncrepl.c:1548
#11 0x00007f2ea59463a2 in ?? () from /usr/lib/x86_64-linux-gnu/libldap_r-2.4.so.2
#12 0x00007f2ea487c6ba in start_thread (arg=0x7f2e95b79700) at pthread_create.c:333
#13 0x00007f2ea45b282d in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:109
Thread 3 (Thread 0x7f2e9637a700 (LWP 42140)):
---Type <return> to continue, or q <return> to quit---
#0 pthread_cond_wait@@GLIBC_2.3.2 () at ../sysdeps/unix/sysv/linux/x86_64/pthread_cond_wait.S:185
#1 0x00007f2ea59463f3 in ?? () from /usr/lib/x86_64-linux-gnu/libldap_r-2.4.so.2
#2 0x00007f2ea487c6ba in start_thread (arg=0x7f2e9637a700) at pthread_create.c:333
#3 0x00007f2ea45b282d in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:109
Thread 2 (Thread 0x7f2e96b7b700 (LWP 42139)):
#0 0x00007f2ea45b2e23 in epoll_wait () at ../sysdeps/unix/syscall-template.S:84
#1 0x0000561fbc55a8f0 in slapd_daemon_task (ptr=<optimized out>) at ../../../../servers/slapd/daemon.c:2539
#2 0x00007f2ea487c6ba in start_thread (arg=0x7f2e96b7b700) at pthread_create.c:333
#3 0x00007f2ea45b282d in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:109
Thread 1 (Thread 0x7f2ea5d96740 (LWP 42138)):
#0 0x00007f2ea487d98d in pthread_join (threadid=139838073845504, thread_return=0x0) at pthread_join.c:90
#1 0x0000561fbc55cc81 in slapd_daemon () at ../../../../servers/slapd/daemon.c:2932
#2 0x0000561fbc543bea in main (argc=11, argv=<optimized out>) at ../../../../servers/slapd/main.c:1017
(gdb) |
[Impact]
* An explanation of the effects of the bug on users and
* justification for backporting the fix to the stable release.
* In addition, it is helpful, but not required, to include an
explanation of how the upload fixes this bug.
[Test Case]
* detailed instructions how to reproduce the bug
* these should allow someone who is not familiar with the affected
package to reproduce the bug and verify that the updated package fixes
the problem.
[Regression Potential]
* discussion of how regressions are most likely to manifest as a result of this change.
* It is assumed that any SRU candidate patch is well-tested before
upload and has a low overall risk of regression, but it's important
to make the effort to think about what ''could'' happen in the
event of a regression.
* This both shows the SRU team that the risks have been considered,
and provides guidance to testers in regression-testing the SRU.
[Other Info]
* Anything else you think is useful to include
* Anticipate questions from users, SRU, +1 maintenance, security teams and the Technical Board
* and address these questions in advance
[Original description]
I have a slapd problem on a freshly installed 16.04 machine:
slapd[17107]: segfault at 1a ip 00007f3c12c79f55 sp 00007f3c03c2d080 error 4 in libsasl2.so.2.0.25[7f3c12c72000+19000]
I'm using the server as Slave LDAP-Server and sync replication with kerberos authentication.
The service either starts and runs successfully or it fails with segmentation fault or 100% CPU.
Maybe an useful info, I'm replicating two databases. When I deactivate syncrepl for one of them (doesn't matter which one) the problem is not occuring.
Linux xxx 4.4.0-75-generic #96-Ubuntu SMP Thu Apr 20 09:56:33 UTC 2017 x86_64 x86_64 x86_64 GNU/Linux
slapd 2.4.42+dfsg-2ubuntu3.1
libsasl2-2:amd64 2.1.26.dfsg1-14build1
libsasl2-modules:amd64 2.1.26.dfsg1-14build1
libsasl2-modules-gssapi-mit:amd64 2.1.26.dfsg1-14build1
GDB debug:
Starting program: /usr/sbin/slapd -h "ldap:/// ldaps:/// ldapi:///" -u openldap -g openldap -f /etc/ldap/slapd.conf -d 256
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
590c82ab @(#) $OpenLDAP: slapd (Ubuntu) (May 11 2016 16:12:05) $
buildd@lgw01-10:/build/openldap-mF7Kfq/openldap-2.4.42+dfsg/debian/build/servers/slapd
590c82ab slapd starting
[New Thread 0x7f2e96b7b700 (LWP 42139)]
[New Thread 0x7f2e9637a700 (LWP 42140)]
[New Thread 0x7f2e95b79700 (LWP 42141)]
[New Thread 0x7f2e95378700 (LWP 42142)]
[New Thread 0x7f2e94b77700 (LWP 42143)]
590c82ba slap_client_connect: URI=ldap://xxx ldap_sasl_interactive_bind_s failed (-6)
590c82ba do_syncrepl: rid=132 rc -6 retrying (9 retries left)
Thread 4 "slapd" received signal SIGSEGV, Segmentation fault.
[Switching to Thread 0x7f2e95b79700 (LWP 42141)]
0x00007f2ea53035b5 in sasl_client_add_plugin () from /usr/lib/x86_64-linux-gnu/libsasl2.so.2
(gdb) thr apply all bt
Thread 6 (Thread 0x7f2e94b77700 (LWP 42143)):
#0 pthread_cond_wait@@GLIBC_2.3.2 () at ../sysdeps/unix/sysv/linux/x86_64/pthread_cond_wait.S:185
#1 0x00007f2ea59463f3 in ?? () from /usr/lib/x86_64-linux-gnu/libldap_r-2.4.so.2
#2 0x00007f2ea487c6ba in start_thread (arg=0x7f2e94b77700) at pthread_create.c:333
#3 0x00007f2ea45b282d in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:109
Thread 5 (Thread 0x7f2e95378700 (LWP 42142)):
#0 pthread_cond_wait@@GLIBC_2.3.2 () at ../sysdeps/unix/sysv/linux/x86_64/pthread_cond_wait.S:185
#1 0x00007f2ea59463f3 in ?? () from /usr/lib/x86_64-linux-gnu/libldap_r-2.4.so.2
#2 0x00007f2ea487c6ba in start_thread (arg=0x7f2e95378700) at pthread_create.c:333
#3 0x00007f2ea45b282d in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:109
Thread 4 (Thread 0x7f2e95b79700 (LWP 42141)):
#0 0x00007f2ea53035b5 in sasl_client_add_plugin () from /usr/lib/x86_64-linux-gnu/libsasl2.so.2
#1 0x00007f2ea530f250 in ?? () from /usr/lib/x86_64-linux-gnu/libsasl2.so.2
#2 0x00007f2ea5303d69 in sasl_client_init () from /usr/lib/x86_64-linux-gnu/libsasl2.so.2
#3 0x00007f2ea594da6c in ldap_int_sasl_init () from /usr/lib/x86_64-linux-gnu/libldap_r-2.4.so.2
#4 0x00007f2ea594db2c in ldap_int_sasl_open () from /usr/lib/x86_64-linux-gnu/libldap_r-2.4.so.2
#5 0x00007f2ea594e2d4 in ldap_int_sasl_bind () from /usr/lib/x86_64-linux-gnu/libldap_r-2.4.so.2
#6 0x00007f2ea5951828 in ldap_sasl_interactive_bind () from /usr/lib/x86_64-linux-gnu/libldap_r-2.4.so.2
#7 0x00007f2ea5951a4e in ldap_sasl_interactive_bind_s () from /usr/lib/x86_64-linux-gnu/libldap_r-2.4.so.2
#8 0x0000561fbc556db4 in slap_client_connect (ldp=0x561fbe1e9f68, sb=0x561fbe1e9d40) at ../../../../servers/slapd/config.c:2063
#9 0x0000561fbc5c699d in do_syncrep1 (si=0x561fbe1e9d10, op=0x7f2e95b787b0) at ../../../../servers/slapd/syncrepl.c:618
#10 do_syncrepl (ctx=<optimized out>, arg=0x561fbe1e5620) at ../../../../servers/slapd/syncrepl.c:1548
#11 0x00007f2ea59463a2 in ?? () from /usr/lib/x86_64-linux-gnu/libldap_r-2.4.so.2
#12 0x00007f2ea487c6ba in start_thread (arg=0x7f2e95b79700) at pthread_create.c:333
#13 0x00007f2ea45b282d in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:109
Thread 3 (Thread 0x7f2e9637a700 (LWP 42140)):
---Type <return> to continue, or q <return> to quit---
#0 pthread_cond_wait@@GLIBC_2.3.2 () at ../sysdeps/unix/sysv/linux/x86_64/pthread_cond_wait.S:185
#1 0x00007f2ea59463f3 in ?? () from /usr/lib/x86_64-linux-gnu/libldap_r-2.4.so.2
#2 0x00007f2ea487c6ba in start_thread (arg=0x7f2e9637a700) at pthread_create.c:333
#3 0x00007f2ea45b282d in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:109
Thread 2 (Thread 0x7f2e96b7b700 (LWP 42139)):
#0 0x00007f2ea45b2e23 in epoll_wait () at ../sysdeps/unix/syscall-template.S:84
#1 0x0000561fbc55a8f0 in slapd_daemon_task (ptr=<optimized out>) at ../../../../servers/slapd/daemon.c:2539
#2 0x00007f2ea487c6ba in start_thread (arg=0x7f2e96b7b700) at pthread_create.c:333
#3 0x00007f2ea45b282d in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:109
Thread 1 (Thread 0x7f2ea5d96740 (LWP 42138)):
#0 0x00007f2ea487d98d in pthread_join (threadid=139838073845504, thread_return=0x0) at pthread_join.c:90
#1 0x0000561fbc55cc81 in slapd_daemon () at ../../../../servers/slapd/daemon.c:2932
#2 0x0000561fbc543bea in main (argc=11, argv=<optimized out>) at ../../../../servers/slapd/main.c:1017
(gdb) |
|
| 2018-05-16 21:15:07 |
Andreas Hasenack |
description |
[Impact]
* An explanation of the effects of the bug on users and
* justification for backporting the fix to the stable release.
* In addition, it is helpful, but not required, to include an
explanation of how the upload fixes this bug.
[Test Case]
* detailed instructions how to reproduce the bug
* these should allow someone who is not familiar with the affected
package to reproduce the bug and verify that the updated package fixes
the problem.
[Regression Potential]
* discussion of how regressions are most likely to manifest as a result of this change.
* It is assumed that any SRU candidate patch is well-tested before
upload and has a low overall risk of regression, but it's important
to make the effort to think about what ''could'' happen in the
event of a regression.
* This both shows the SRU team that the risks have been considered,
and provides guidance to testers in regression-testing the SRU.
[Other Info]
* Anything else you think is useful to include
* Anticipate questions from users, SRU, +1 maintenance, security teams and the Technical Board
* and address these questions in advance
[Original description]
I have a slapd problem on a freshly installed 16.04 machine:
slapd[17107]: segfault at 1a ip 00007f3c12c79f55 sp 00007f3c03c2d080 error 4 in libsasl2.so.2.0.25[7f3c12c72000+19000]
I'm using the server as Slave LDAP-Server and sync replication with kerberos authentication.
The service either starts and runs successfully or it fails with segmentation fault or 100% CPU.
Maybe an useful info, I'm replicating two databases. When I deactivate syncrepl for one of them (doesn't matter which one) the problem is not occuring.
Linux xxx 4.4.0-75-generic #96-Ubuntu SMP Thu Apr 20 09:56:33 UTC 2017 x86_64 x86_64 x86_64 GNU/Linux
slapd 2.4.42+dfsg-2ubuntu3.1
libsasl2-2:amd64 2.1.26.dfsg1-14build1
libsasl2-modules:amd64 2.1.26.dfsg1-14build1
libsasl2-modules-gssapi-mit:amd64 2.1.26.dfsg1-14build1
GDB debug:
Starting program: /usr/sbin/slapd -h "ldap:/// ldaps:/// ldapi:///" -u openldap -g openldap -f /etc/ldap/slapd.conf -d 256
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
590c82ab @(#) $OpenLDAP: slapd (Ubuntu) (May 11 2016 16:12:05) $
buildd@lgw01-10:/build/openldap-mF7Kfq/openldap-2.4.42+dfsg/debian/build/servers/slapd
590c82ab slapd starting
[New Thread 0x7f2e96b7b700 (LWP 42139)]
[New Thread 0x7f2e9637a700 (LWP 42140)]
[New Thread 0x7f2e95b79700 (LWP 42141)]
[New Thread 0x7f2e95378700 (LWP 42142)]
[New Thread 0x7f2e94b77700 (LWP 42143)]
590c82ba slap_client_connect: URI=ldap://xxx ldap_sasl_interactive_bind_s failed (-6)
590c82ba do_syncrepl: rid=132 rc -6 retrying (9 retries left)
Thread 4 "slapd" received signal SIGSEGV, Segmentation fault.
[Switching to Thread 0x7f2e95b79700 (LWP 42141)]
0x00007f2ea53035b5 in sasl_client_add_plugin () from /usr/lib/x86_64-linux-gnu/libsasl2.so.2
(gdb) thr apply all bt
Thread 6 (Thread 0x7f2e94b77700 (LWP 42143)):
#0 pthread_cond_wait@@GLIBC_2.3.2 () at ../sysdeps/unix/sysv/linux/x86_64/pthread_cond_wait.S:185
#1 0x00007f2ea59463f3 in ?? () from /usr/lib/x86_64-linux-gnu/libldap_r-2.4.so.2
#2 0x00007f2ea487c6ba in start_thread (arg=0x7f2e94b77700) at pthread_create.c:333
#3 0x00007f2ea45b282d in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:109
Thread 5 (Thread 0x7f2e95378700 (LWP 42142)):
#0 pthread_cond_wait@@GLIBC_2.3.2 () at ../sysdeps/unix/sysv/linux/x86_64/pthread_cond_wait.S:185
#1 0x00007f2ea59463f3 in ?? () from /usr/lib/x86_64-linux-gnu/libldap_r-2.4.so.2
#2 0x00007f2ea487c6ba in start_thread (arg=0x7f2e95378700) at pthread_create.c:333
#3 0x00007f2ea45b282d in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:109
Thread 4 (Thread 0x7f2e95b79700 (LWP 42141)):
#0 0x00007f2ea53035b5 in sasl_client_add_plugin () from /usr/lib/x86_64-linux-gnu/libsasl2.so.2
#1 0x00007f2ea530f250 in ?? () from /usr/lib/x86_64-linux-gnu/libsasl2.so.2
#2 0x00007f2ea5303d69 in sasl_client_init () from /usr/lib/x86_64-linux-gnu/libsasl2.so.2
#3 0x00007f2ea594da6c in ldap_int_sasl_init () from /usr/lib/x86_64-linux-gnu/libldap_r-2.4.so.2
#4 0x00007f2ea594db2c in ldap_int_sasl_open () from /usr/lib/x86_64-linux-gnu/libldap_r-2.4.so.2
#5 0x00007f2ea594e2d4 in ldap_int_sasl_bind () from /usr/lib/x86_64-linux-gnu/libldap_r-2.4.so.2
#6 0x00007f2ea5951828 in ldap_sasl_interactive_bind () from /usr/lib/x86_64-linux-gnu/libldap_r-2.4.so.2
#7 0x00007f2ea5951a4e in ldap_sasl_interactive_bind_s () from /usr/lib/x86_64-linux-gnu/libldap_r-2.4.so.2
#8 0x0000561fbc556db4 in slap_client_connect (ldp=0x561fbe1e9f68, sb=0x561fbe1e9d40) at ../../../../servers/slapd/config.c:2063
#9 0x0000561fbc5c699d in do_syncrep1 (si=0x561fbe1e9d10, op=0x7f2e95b787b0) at ../../../../servers/slapd/syncrepl.c:618
#10 do_syncrepl (ctx=<optimized out>, arg=0x561fbe1e5620) at ../../../../servers/slapd/syncrepl.c:1548
#11 0x00007f2ea59463a2 in ?? () from /usr/lib/x86_64-linux-gnu/libldap_r-2.4.so.2
#12 0x00007f2ea487c6ba in start_thread (arg=0x7f2e95b79700) at pthread_create.c:333
#13 0x00007f2ea45b282d in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:109
Thread 3 (Thread 0x7f2e9637a700 (LWP 42140)):
---Type <return> to continue, or q <return> to quit---
#0 pthread_cond_wait@@GLIBC_2.3.2 () at ../sysdeps/unix/sysv/linux/x86_64/pthread_cond_wait.S:185
#1 0x00007f2ea59463f3 in ?? () from /usr/lib/x86_64-linux-gnu/libldap_r-2.4.so.2
#2 0x00007f2ea487c6ba in start_thread (arg=0x7f2e9637a700) at pthread_create.c:333
#3 0x00007f2ea45b282d in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:109
Thread 2 (Thread 0x7f2e96b7b700 (LWP 42139)):
#0 0x00007f2ea45b2e23 in epoll_wait () at ../sysdeps/unix/syscall-template.S:84
#1 0x0000561fbc55a8f0 in slapd_daemon_task (ptr=<optimized out>) at ../../../../servers/slapd/daemon.c:2539
#2 0x00007f2ea487c6ba in start_thread (arg=0x7f2e96b7b700) at pthread_create.c:333
#3 0x00007f2ea45b282d in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:109
Thread 1 (Thread 0x7f2ea5d96740 (LWP 42138)):
#0 0x00007f2ea487d98d in pthread_join (threadid=139838073845504, thread_return=0x0) at pthread_join.c:90
#1 0x0000561fbc55cc81 in slapd_daemon () at ../../../../servers/slapd/daemon.c:2932
#2 0x0000561fbc543bea in main (argc=11, argv=<optimized out>) at ../../../../servers/slapd/main.c:1017
(gdb) |
[Impact]
Concurrent SASL authentications could trigger a segfault. This was observed by the bug reporter during replication from a master to a slave, and can be reproduced with a test program.
The fix is applied upstream, see comment #13.
[Test Case]
* Create a fresh xenial VM or container and login. Update the apt repositories:
sudo apt update
* Create a local directory and cd into it:
mkdir test && cd test
* Download the test attachments from this bug: Makefile, sasltest.c and testscript:
wget https://bugs.launchpad.net/ubuntu/+source/openldap/+bug/1688575/+attachment/5139678/+files/Makefile https://bugs.launchpad.net/ubuntu/+source/openldap/+bug/1688575/+attachment/5139679/+files/sasltest.c https://bugs.launchpad.net/ubuntu/+source/openldap/+bug/1688575/+attachment/5139680/+files/testscript
* Execute the testscript with sudo once. It shall fail at the very end with a core dump:
sudo sh ./testscript
(...)
sasltest: sasltest.c:70: bind_thread: Assertion `rc == LDAP_SUCCESS' failed.
Aborted (core dumped)
* Export this var:
export LDAPSASL_SECPROPS=none
* Run the actual test script a few more times to confirm the crasH:
$ ./sasltest
rc = -6 (Unknown authentication method)
sasltest: sasltest.c:70: bind_thread: Assertion `rc == LDAP_SUCCESS' failed.
rc = -6 (Unknown authentication method)
sasltest: sasltest.c:70: bind_thread: Assertion `rc == LDAP_SUCCESS' failed.
rc = -6 (Unknown authentication method)
sasltest: sasltest.c:70: bind_thread: Assertion `rc == LDAP_SUCCESS' failed.
Aborted (core dumped)
* Install the updated packages from proposed
* Run ./sasltest again. Make sure the LDAPSASL_SECPROPS var is still exported:
$ echo $LDAPSASL_SECPROPS
none
$ ./sasltest
$
This time the test completes without crashing.
[Regression Potential]
* discussion of how regressions are most likely to manifest as a result of this change.
* It is assumed that any SRU candidate patch is well-tested before
upload and has a low overall risk of regression, but it's important
to make the effort to think about what ''could'' happen in the
event of a regression.
* This both shows the SRU team that the risks have been considered,
and provides guidance to testers in regression-testing the SRU.
[Other Info]
* Anything else you think is useful to include
* Anticipate questions from users, SRU, +1 maintenance, security teams and the Technical Board
* and address these questions in advance
[Original description]
I have a slapd problem on a freshly installed 16.04 machine:
slapd[17107]: segfault at 1a ip 00007f3c12c79f55 sp 00007f3c03c2d080 error 4 in libsasl2.so.2.0.25[7f3c12c72000+19000]
I'm using the server as Slave LDAP-Server and sync replication with kerberos authentication.
The service either starts and runs successfully or it fails with segmentation fault or 100% CPU.
Maybe an useful info, I'm replicating two databases. When I deactivate syncrepl for one of them (doesn't matter which one) the problem is not occuring.
Linux xxx 4.4.0-75-generic #96-Ubuntu SMP Thu Apr 20 09:56:33 UTC 2017 x86_64 x86_64 x86_64 GNU/Linux
slapd 2.4.42+dfsg-2ubuntu3.1
libsasl2-2:amd64 2.1.26.dfsg1-14build1
libsasl2-modules:amd64 2.1.26.dfsg1-14build1
libsasl2-modules-gssapi-mit:amd64 2.1.26.dfsg1-14build1
GDB debug:
Starting program: /usr/sbin/slapd -h "ldap:/// ldaps:/// ldapi:///" -u openldap -g openldap -f /etc/ldap/slapd.conf -d 256
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
590c82ab @(#) $OpenLDAP: slapd (Ubuntu) (May 11 2016 16:12:05) $
buildd@lgw01-10:/build/openldap-mF7Kfq/openldap-2.4.42+dfsg/debian/build/servers/slapd
590c82ab slapd starting
[New Thread 0x7f2e96b7b700 (LWP 42139)]
[New Thread 0x7f2e9637a700 (LWP 42140)]
[New Thread 0x7f2e95b79700 (LWP 42141)]
[New Thread 0x7f2e95378700 (LWP 42142)]
[New Thread 0x7f2e94b77700 (LWP 42143)]
590c82ba slap_client_connect: URI=ldap://xxx ldap_sasl_interactive_bind_s failed (-6)
590c82ba do_syncrepl: rid=132 rc -6 retrying (9 retries left)
Thread 4 "slapd" received signal SIGSEGV, Segmentation fault.
[Switching to Thread 0x7f2e95b79700 (LWP 42141)]
0x00007f2ea53035b5 in sasl_client_add_plugin () from /usr/lib/x86_64-linux-gnu/libsasl2.so.2
(gdb) thr apply all bt
Thread 6 (Thread 0x7f2e94b77700 (LWP 42143)):
#0 pthread_cond_wait@@GLIBC_2.3.2 () at ../sysdeps/unix/sysv/linux/x86_64/pthread_cond_wait.S:185
#1 0x00007f2ea59463f3 in ?? () from /usr/lib/x86_64-linux-gnu/libldap_r-2.4.so.2
#2 0x00007f2ea487c6ba in start_thread (arg=0x7f2e94b77700) at pthread_create.c:333
#3 0x00007f2ea45b282d in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:109
Thread 5 (Thread 0x7f2e95378700 (LWP 42142)):
#0 pthread_cond_wait@@GLIBC_2.3.2 () at ../sysdeps/unix/sysv/linux/x86_64/pthread_cond_wait.S:185
#1 0x00007f2ea59463f3 in ?? () from /usr/lib/x86_64-linux-gnu/libldap_r-2.4.so.2
#2 0x00007f2ea487c6ba in start_thread (arg=0x7f2e95378700) at pthread_create.c:333
#3 0x00007f2ea45b282d in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:109
Thread 4 (Thread 0x7f2e95b79700 (LWP 42141)):
#0 0x00007f2ea53035b5 in sasl_client_add_plugin () from /usr/lib/x86_64-linux-gnu/libsasl2.so.2
#1 0x00007f2ea530f250 in ?? () from /usr/lib/x86_64-linux-gnu/libsasl2.so.2
#2 0x00007f2ea5303d69 in sasl_client_init () from /usr/lib/x86_64-linux-gnu/libsasl2.so.2
#3 0x00007f2ea594da6c in ldap_int_sasl_init () from /usr/lib/x86_64-linux-gnu/libldap_r-2.4.so.2
#4 0x00007f2ea594db2c in ldap_int_sasl_open () from /usr/lib/x86_64-linux-gnu/libldap_r-2.4.so.2
#5 0x00007f2ea594e2d4 in ldap_int_sasl_bind () from /usr/lib/x86_64-linux-gnu/libldap_r-2.4.so.2
#6 0x00007f2ea5951828 in ldap_sasl_interactive_bind () from /usr/lib/x86_64-linux-gnu/libldap_r-2.4.so.2
#7 0x00007f2ea5951a4e in ldap_sasl_interactive_bind_s () from /usr/lib/x86_64-linux-gnu/libldap_r-2.4.so.2
#8 0x0000561fbc556db4 in slap_client_connect (ldp=0x561fbe1e9f68, sb=0x561fbe1e9d40) at ../../../../servers/slapd/config.c:2063
#9 0x0000561fbc5c699d in do_syncrep1 (si=0x561fbe1e9d10, op=0x7f2e95b787b0) at ../../../../servers/slapd/syncrepl.c:618
#10 do_syncrepl (ctx=<optimized out>, arg=0x561fbe1e5620) at ../../../../servers/slapd/syncrepl.c:1548
#11 0x00007f2ea59463a2 in ?? () from /usr/lib/x86_64-linux-gnu/libldap_r-2.4.so.2
#12 0x00007f2ea487c6ba in start_thread (arg=0x7f2e95b79700) at pthread_create.c:333
#13 0x00007f2ea45b282d in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:109
Thread 3 (Thread 0x7f2e9637a700 (LWP 42140)):
---Type <return> to continue, or q <return> to quit---
#0 pthread_cond_wait@@GLIBC_2.3.2 () at ../sysdeps/unix/sysv/linux/x86_64/pthread_cond_wait.S:185
#1 0x00007f2ea59463f3 in ?? () from /usr/lib/x86_64-linux-gnu/libldap_r-2.4.so.2
#2 0x00007f2ea487c6ba in start_thread (arg=0x7f2e9637a700) at pthread_create.c:333
#3 0x00007f2ea45b282d in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:109
Thread 2 (Thread 0x7f2e96b7b700 (LWP 42139)):
#0 0x00007f2ea45b2e23 in epoll_wait () at ../sysdeps/unix/syscall-template.S:84
#1 0x0000561fbc55a8f0 in slapd_daemon_task (ptr=<optimized out>) at ../../../../servers/slapd/daemon.c:2539
#2 0x00007f2ea487c6ba in start_thread (arg=0x7f2e96b7b700) at pthread_create.c:333
#3 0x00007f2ea45b282d in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:109
Thread 1 (Thread 0x7f2ea5d96740 (LWP 42138)):
#0 0x00007f2ea487d98d in pthread_join (threadid=139838073845504, thread_return=0x0) at pthread_join.c:90
#1 0x0000561fbc55cc81 in slapd_daemon () at ../../../../servers/slapd/daemon.c:2932
#2 0x0000561fbc543bea in main (argc=11, argv=<optimized out>) at ../../../../servers/slapd/main.c:1017
(gdb) |
|
| 2018-05-18 18:15:42 |
Andreas Hasenack |
description |
[Impact]
Concurrent SASL authentications could trigger a segfault. This was observed by the bug reporter during replication from a master to a slave, and can be reproduced with a test program.
The fix is applied upstream, see comment #13.
[Test Case]
* Create a fresh xenial VM or container and login. Update the apt repositories:
sudo apt update
* Create a local directory and cd into it:
mkdir test && cd test
* Download the test attachments from this bug: Makefile, sasltest.c and testscript:
wget https://bugs.launchpad.net/ubuntu/+source/openldap/+bug/1688575/+attachment/5139678/+files/Makefile https://bugs.launchpad.net/ubuntu/+source/openldap/+bug/1688575/+attachment/5139679/+files/sasltest.c https://bugs.launchpad.net/ubuntu/+source/openldap/+bug/1688575/+attachment/5139680/+files/testscript
* Execute the testscript with sudo once. It shall fail at the very end with a core dump:
sudo sh ./testscript
(...)
sasltest: sasltest.c:70: bind_thread: Assertion `rc == LDAP_SUCCESS' failed.
Aborted (core dumped)
* Export this var:
export LDAPSASL_SECPROPS=none
* Run the actual test script a few more times to confirm the crasH:
$ ./sasltest
rc = -6 (Unknown authentication method)
sasltest: sasltest.c:70: bind_thread: Assertion `rc == LDAP_SUCCESS' failed.
rc = -6 (Unknown authentication method)
sasltest: sasltest.c:70: bind_thread: Assertion `rc == LDAP_SUCCESS' failed.
rc = -6 (Unknown authentication method)
sasltest: sasltest.c:70: bind_thread: Assertion `rc == LDAP_SUCCESS' failed.
Aborted (core dumped)
* Install the updated packages from proposed
* Run ./sasltest again. Make sure the LDAPSASL_SECPROPS var is still exported:
$ echo $LDAPSASL_SECPROPS
none
$ ./sasltest
$
This time the test completes without crashing.
[Regression Potential]
* discussion of how regressions are most likely to manifest as a result of this change.
* It is assumed that any SRU candidate patch is well-tested before
upload and has a low overall risk of regression, but it's important
to make the effort to think about what ''could'' happen in the
event of a regression.
* This both shows the SRU team that the risks have been considered,
and provides guidance to testers in regression-testing the SRU.
[Other Info]
* Anything else you think is useful to include
* Anticipate questions from users, SRU, +1 maintenance, security teams and the Technical Board
* and address these questions in advance
[Original description]
I have a slapd problem on a freshly installed 16.04 machine:
slapd[17107]: segfault at 1a ip 00007f3c12c79f55 sp 00007f3c03c2d080 error 4 in libsasl2.so.2.0.25[7f3c12c72000+19000]
I'm using the server as Slave LDAP-Server and sync replication with kerberos authentication.
The service either starts and runs successfully or it fails with segmentation fault or 100% CPU.
Maybe an useful info, I'm replicating two databases. When I deactivate syncrepl for one of them (doesn't matter which one) the problem is not occuring.
Linux xxx 4.4.0-75-generic #96-Ubuntu SMP Thu Apr 20 09:56:33 UTC 2017 x86_64 x86_64 x86_64 GNU/Linux
slapd 2.4.42+dfsg-2ubuntu3.1
libsasl2-2:amd64 2.1.26.dfsg1-14build1
libsasl2-modules:amd64 2.1.26.dfsg1-14build1
libsasl2-modules-gssapi-mit:amd64 2.1.26.dfsg1-14build1
GDB debug:
Starting program: /usr/sbin/slapd -h "ldap:/// ldaps:/// ldapi:///" -u openldap -g openldap -f /etc/ldap/slapd.conf -d 256
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
590c82ab @(#) $OpenLDAP: slapd (Ubuntu) (May 11 2016 16:12:05) $
buildd@lgw01-10:/build/openldap-mF7Kfq/openldap-2.4.42+dfsg/debian/build/servers/slapd
590c82ab slapd starting
[New Thread 0x7f2e96b7b700 (LWP 42139)]
[New Thread 0x7f2e9637a700 (LWP 42140)]
[New Thread 0x7f2e95b79700 (LWP 42141)]
[New Thread 0x7f2e95378700 (LWP 42142)]
[New Thread 0x7f2e94b77700 (LWP 42143)]
590c82ba slap_client_connect: URI=ldap://xxx ldap_sasl_interactive_bind_s failed (-6)
590c82ba do_syncrepl: rid=132 rc -6 retrying (9 retries left)
Thread 4 "slapd" received signal SIGSEGV, Segmentation fault.
[Switching to Thread 0x7f2e95b79700 (LWP 42141)]
0x00007f2ea53035b5 in sasl_client_add_plugin () from /usr/lib/x86_64-linux-gnu/libsasl2.so.2
(gdb) thr apply all bt
Thread 6 (Thread 0x7f2e94b77700 (LWP 42143)):
#0 pthread_cond_wait@@GLIBC_2.3.2 () at ../sysdeps/unix/sysv/linux/x86_64/pthread_cond_wait.S:185
#1 0x00007f2ea59463f3 in ?? () from /usr/lib/x86_64-linux-gnu/libldap_r-2.4.so.2
#2 0x00007f2ea487c6ba in start_thread (arg=0x7f2e94b77700) at pthread_create.c:333
#3 0x00007f2ea45b282d in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:109
Thread 5 (Thread 0x7f2e95378700 (LWP 42142)):
#0 pthread_cond_wait@@GLIBC_2.3.2 () at ../sysdeps/unix/sysv/linux/x86_64/pthread_cond_wait.S:185
#1 0x00007f2ea59463f3 in ?? () from /usr/lib/x86_64-linux-gnu/libldap_r-2.4.so.2
#2 0x00007f2ea487c6ba in start_thread (arg=0x7f2e95378700) at pthread_create.c:333
#3 0x00007f2ea45b282d in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:109
Thread 4 (Thread 0x7f2e95b79700 (LWP 42141)):
#0 0x00007f2ea53035b5 in sasl_client_add_plugin () from /usr/lib/x86_64-linux-gnu/libsasl2.so.2
#1 0x00007f2ea530f250 in ?? () from /usr/lib/x86_64-linux-gnu/libsasl2.so.2
#2 0x00007f2ea5303d69 in sasl_client_init () from /usr/lib/x86_64-linux-gnu/libsasl2.so.2
#3 0x00007f2ea594da6c in ldap_int_sasl_init () from /usr/lib/x86_64-linux-gnu/libldap_r-2.4.so.2
#4 0x00007f2ea594db2c in ldap_int_sasl_open () from /usr/lib/x86_64-linux-gnu/libldap_r-2.4.so.2
#5 0x00007f2ea594e2d4 in ldap_int_sasl_bind () from /usr/lib/x86_64-linux-gnu/libldap_r-2.4.so.2
#6 0x00007f2ea5951828 in ldap_sasl_interactive_bind () from /usr/lib/x86_64-linux-gnu/libldap_r-2.4.so.2
#7 0x00007f2ea5951a4e in ldap_sasl_interactive_bind_s () from /usr/lib/x86_64-linux-gnu/libldap_r-2.4.so.2
#8 0x0000561fbc556db4 in slap_client_connect (ldp=0x561fbe1e9f68, sb=0x561fbe1e9d40) at ../../../../servers/slapd/config.c:2063
#9 0x0000561fbc5c699d in do_syncrep1 (si=0x561fbe1e9d10, op=0x7f2e95b787b0) at ../../../../servers/slapd/syncrepl.c:618
#10 do_syncrepl (ctx=<optimized out>, arg=0x561fbe1e5620) at ../../../../servers/slapd/syncrepl.c:1548
#11 0x00007f2ea59463a2 in ?? () from /usr/lib/x86_64-linux-gnu/libldap_r-2.4.so.2
#12 0x00007f2ea487c6ba in start_thread (arg=0x7f2e95b79700) at pthread_create.c:333
#13 0x00007f2ea45b282d in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:109
Thread 3 (Thread 0x7f2e9637a700 (LWP 42140)):
---Type <return> to continue, or q <return> to quit---
#0 pthread_cond_wait@@GLIBC_2.3.2 () at ../sysdeps/unix/sysv/linux/x86_64/pthread_cond_wait.S:185
#1 0x00007f2ea59463f3 in ?? () from /usr/lib/x86_64-linux-gnu/libldap_r-2.4.so.2
#2 0x00007f2ea487c6ba in start_thread (arg=0x7f2e9637a700) at pthread_create.c:333
#3 0x00007f2ea45b282d in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:109
Thread 2 (Thread 0x7f2e96b7b700 (LWP 42139)):
#0 0x00007f2ea45b2e23 in epoll_wait () at ../sysdeps/unix/syscall-template.S:84
#1 0x0000561fbc55a8f0 in slapd_daemon_task (ptr=<optimized out>) at ../../../../servers/slapd/daemon.c:2539
#2 0x00007f2ea487c6ba in start_thread (arg=0x7f2e96b7b700) at pthread_create.c:333
#3 0x00007f2ea45b282d in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:109
Thread 1 (Thread 0x7f2ea5d96740 (LWP 42138)):
#0 0x00007f2ea487d98d in pthread_join (threadid=139838073845504, thread_return=0x0) at pthread_join.c:90
#1 0x0000561fbc55cc81 in slapd_daemon () at ../../../../servers/slapd/daemon.c:2932
#2 0x0000561fbc543bea in main (argc=11, argv=<optimized out>) at ../../../../servers/slapd/main.c:1017
(gdb) |
[Impact]
Concurrent SASL authentications could trigger a segfault. This was observed by the bug reporter during replication from a master to a slave, and can be reproduced with a test program.
The fix is applied upstream, see comment #13.
[Test Case]
* Create a fresh xenial VM or container and login. Update the apt repositories:
sudo apt update
* Create a local directory and cd into it:
mkdir test && cd test
* Download the test attachments from this bug: Makefile, sasltest.c and testscript:
wget https://bugs.launchpad.net/ubuntu/+source/openldap/+bug/1688575/+attachment/5139678/+files/Makefile https://bugs.launchpad.net/ubuntu/+source/openldap/+bug/1688575/+attachment/5139679/+files/sasltest.c https://bugs.launchpad.net/ubuntu/+source/openldap/+bug/1688575/+attachment/5139680/+files/testscript
* Execute the testscript with sudo once. It shall fail at the very end with a core dump:
sudo sh ./testscript
(...)
sasltest: sasltest.c:70: bind_thread: Assertion `rc == LDAP_SUCCESS' failed.
Aborted (core dumped)
* Export this var:
export LDAPSASL_SECPROPS=none
* Run the actual test script a few more times to confirm the crasH:
$ ./sasltest
rc = -6 (Unknown authentication method)
sasltest: sasltest.c:70: bind_thread: Assertion `rc == LDAP_SUCCESS' failed.
rc = -6 (Unknown authentication method)
sasltest: sasltest.c:70: bind_thread: Assertion `rc == LDAP_SUCCESS' failed.
rc = -6 (Unknown authentication method)
sasltest: sasltest.c:70: bind_thread: Assertion `rc == LDAP_SUCCESS' failed.
Aborted (core dumped)
* Install the updated packages from proposed
* Run ./sasltest again. Make sure the LDAPSASL_SECPROPS var is still exported:
$ echo $LDAPSASL_SECPROPS
none
$ ./sasltest
$
This time the test completes without crashing.
[Regression Potential]
This is SASL authentication, and with kerberos nonetheless (in the case of the bug reporter). I suspect not many people deploy this due to its complexity. The ones that have such a setup, however, tend to know what they are doing, so if they say the problem is fixed for them, I believe it is.
About this particular change, it's committed upstream and also in debian, and @rtandy was kind enough to provide a sample test script that exhibits the problem.
[Other Info]
Since the fix is applied upstream and in Debian, there shouldn't be additional surprises here.
[Original description]
I have a slapd problem on a freshly installed 16.04 machine:
slapd[17107]: segfault at 1a ip 00007f3c12c79f55 sp 00007f3c03c2d080 error 4 in libsasl2.so.2.0.25[7f3c12c72000+19000]
I'm using the server as Slave LDAP-Server and sync replication with kerberos authentication.
The service either starts and runs successfully or it fails with segmentation fault or 100% CPU.
Maybe an useful info, I'm replicating two databases. When I deactivate syncrepl for one of them (doesn't matter which one) the problem is not occuring.
Linux xxx 4.4.0-75-generic #96-Ubuntu SMP Thu Apr 20 09:56:33 UTC 2017 x86_64 x86_64 x86_64 GNU/Linux
slapd 2.4.42+dfsg-2ubuntu3.1
libsasl2-2:amd64 2.1.26.dfsg1-14build1
libsasl2-modules:amd64 2.1.26.dfsg1-14build1
libsasl2-modules-gssapi-mit:amd64 2.1.26.dfsg1-14build1
GDB debug:
Starting program: /usr/sbin/slapd -h "ldap:/// ldaps:/// ldapi:///" -u openldap -g openldap -f /etc/ldap/slapd.conf -d 256
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
590c82ab @(#) $OpenLDAP: slapd (Ubuntu) (May 11 2016 16:12:05) $
buildd@lgw01-10:/build/openldap-mF7Kfq/openldap-2.4.42+dfsg/debian/build/servers/slapd
590c82ab slapd starting
[New Thread 0x7f2e96b7b700 (LWP 42139)]
[New Thread 0x7f2e9637a700 (LWP 42140)]
[New Thread 0x7f2e95b79700 (LWP 42141)]
[New Thread 0x7f2e95378700 (LWP 42142)]
[New Thread 0x7f2e94b77700 (LWP 42143)]
590c82ba slap_client_connect: URI=ldap://xxx ldap_sasl_interactive_bind_s failed (-6)
590c82ba do_syncrepl: rid=132 rc -6 retrying (9 retries left)
Thread 4 "slapd" received signal SIGSEGV, Segmentation fault.
[Switching to Thread 0x7f2e95b79700 (LWP 42141)]
0x00007f2ea53035b5 in sasl_client_add_plugin () from /usr/lib/x86_64-linux-gnu/libsasl2.so.2
(gdb) thr apply all bt
Thread 6 (Thread 0x7f2e94b77700 (LWP 42143)):
#0 pthread_cond_wait@@GLIBC_2.3.2 () at ../sysdeps/unix/sysv/linux/x86_64/pthread_cond_wait.S:185
#1 0x00007f2ea59463f3 in ?? () from /usr/lib/x86_64-linux-gnu/libldap_r-2.4.so.2
#2 0x00007f2ea487c6ba in start_thread (arg=0x7f2e94b77700) at pthread_create.c:333
#3 0x00007f2ea45b282d in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:109
Thread 5 (Thread 0x7f2e95378700 (LWP 42142)):
#0 pthread_cond_wait@@GLIBC_2.3.2 () at ../sysdeps/unix/sysv/linux/x86_64/pthread_cond_wait.S:185
#1 0x00007f2ea59463f3 in ?? () from /usr/lib/x86_64-linux-gnu/libldap_r-2.4.so.2
#2 0x00007f2ea487c6ba in start_thread (arg=0x7f2e95378700) at pthread_create.c:333
#3 0x00007f2ea45b282d in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:109
Thread 4 (Thread 0x7f2e95b79700 (LWP 42141)):
#0 0x00007f2ea53035b5 in sasl_client_add_plugin () from /usr/lib/x86_64-linux-gnu/libsasl2.so.2
#1 0x00007f2ea530f250 in ?? () from /usr/lib/x86_64-linux-gnu/libsasl2.so.2
#2 0x00007f2ea5303d69 in sasl_client_init () from /usr/lib/x86_64-linux-gnu/libsasl2.so.2
#3 0x00007f2ea594da6c in ldap_int_sasl_init () from /usr/lib/x86_64-linux-gnu/libldap_r-2.4.so.2
#4 0x00007f2ea594db2c in ldap_int_sasl_open () from /usr/lib/x86_64-linux-gnu/libldap_r-2.4.so.2
#5 0x00007f2ea594e2d4 in ldap_int_sasl_bind () from /usr/lib/x86_64-linux-gnu/libldap_r-2.4.so.2
#6 0x00007f2ea5951828 in ldap_sasl_interactive_bind () from /usr/lib/x86_64-linux-gnu/libldap_r-2.4.so.2
#7 0x00007f2ea5951a4e in ldap_sasl_interactive_bind_s () from /usr/lib/x86_64-linux-gnu/libldap_r-2.4.so.2
#8 0x0000561fbc556db4 in slap_client_connect (ldp=0x561fbe1e9f68, sb=0x561fbe1e9d40) at ../../../../servers/slapd/config.c:2063
#9 0x0000561fbc5c699d in do_syncrep1 (si=0x561fbe1e9d10, op=0x7f2e95b787b0) at ../../../../servers/slapd/syncrepl.c:618
#10 do_syncrepl (ctx=<optimized out>, arg=0x561fbe1e5620) at ../../../../servers/slapd/syncrepl.c:1548
#11 0x00007f2ea59463a2 in ?? () from /usr/lib/x86_64-linux-gnu/libldap_r-2.4.so.2
#12 0x00007f2ea487c6ba in start_thread (arg=0x7f2e95b79700) at pthread_create.c:333
#13 0x00007f2ea45b282d in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:109
Thread 3 (Thread 0x7f2e9637a700 (LWP 42140)):
---Type <return> to continue, or q <return> to quit---
#0 pthread_cond_wait@@GLIBC_2.3.2 () at ../sysdeps/unix/sysv/linux/x86_64/pthread_cond_wait.S:185
#1 0x00007f2ea59463f3 in ?? () from /usr/lib/x86_64-linux-gnu/libldap_r-2.4.so.2
#2 0x00007f2ea487c6ba in start_thread (arg=0x7f2e9637a700) at pthread_create.c:333
#3 0x00007f2ea45b282d in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:109
Thread 2 (Thread 0x7f2e96b7b700 (LWP 42139)):
#0 0x00007f2ea45b2e23 in epoll_wait () at ../sysdeps/unix/syscall-template.S:84
#1 0x0000561fbc55a8f0 in slapd_daemon_task (ptr=<optimized out>) at ../../../../servers/slapd/daemon.c:2539
#2 0x00007f2ea487c6ba in start_thread (arg=0x7f2e96b7b700) at pthread_create.c:333
#3 0x00007f2ea45b282d in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:109
Thread 1 (Thread 0x7f2ea5d96740 (LWP 42138)):
#0 0x00007f2ea487d98d in pthread_join (threadid=139838073845504, thread_return=0x0) at pthread_join.c:90
#1 0x0000561fbc55cc81 in slapd_daemon () at ../../../../servers/slapd/daemon.c:2932
#2 0x0000561fbc543bea in main (argc=11, argv=<optimized out>) at ../../../../servers/slapd/main.c:1017
(gdb) |
|
| 2018-05-18 18:18:34 |
Launchpad Janitor |
merge proposal linked |
|
https://code.launchpad.net/~ahasenack/ubuntu/+source/openldap/+git/openldap/+merge/345944 |
|
| 2018-05-18 18:19:05 |
Andreas Hasenack |
openldap (Ubuntu Xenial): status |
Triaged |
In Progress |
|
| 2018-05-22 10:39:09 |
Christian Ehrhardt |
description |
[Impact]
Concurrent SASL authentications could trigger a segfault. This was observed by the bug reporter during replication from a master to a slave, and can be reproduced with a test program.
The fix is applied upstream, see comment #13.
[Test Case]
* Create a fresh xenial VM or container and login. Update the apt repositories:
sudo apt update
* Create a local directory and cd into it:
mkdir test && cd test
* Download the test attachments from this bug: Makefile, sasltest.c and testscript:
wget https://bugs.launchpad.net/ubuntu/+source/openldap/+bug/1688575/+attachment/5139678/+files/Makefile https://bugs.launchpad.net/ubuntu/+source/openldap/+bug/1688575/+attachment/5139679/+files/sasltest.c https://bugs.launchpad.net/ubuntu/+source/openldap/+bug/1688575/+attachment/5139680/+files/testscript
* Execute the testscript with sudo once. It shall fail at the very end with a core dump:
sudo sh ./testscript
(...)
sasltest: sasltest.c:70: bind_thread: Assertion `rc == LDAP_SUCCESS' failed.
Aborted (core dumped)
* Export this var:
export LDAPSASL_SECPROPS=none
* Run the actual test script a few more times to confirm the crasH:
$ ./sasltest
rc = -6 (Unknown authentication method)
sasltest: sasltest.c:70: bind_thread: Assertion `rc == LDAP_SUCCESS' failed.
rc = -6 (Unknown authentication method)
sasltest: sasltest.c:70: bind_thread: Assertion `rc == LDAP_SUCCESS' failed.
rc = -6 (Unknown authentication method)
sasltest: sasltest.c:70: bind_thread: Assertion `rc == LDAP_SUCCESS' failed.
Aborted (core dumped)
* Install the updated packages from proposed
* Run ./sasltest again. Make sure the LDAPSASL_SECPROPS var is still exported:
$ echo $LDAPSASL_SECPROPS
none
$ ./sasltest
$
This time the test completes without crashing.
[Regression Potential]
This is SASL authentication, and with kerberos nonetheless (in the case of the bug reporter). I suspect not many people deploy this due to its complexity. The ones that have such a setup, however, tend to know what they are doing, so if they say the problem is fixed for them, I believe it is.
About this particular change, it's committed upstream and also in debian, and @rtandy was kind enough to provide a sample test script that exhibits the problem.
[Other Info]
Since the fix is applied upstream and in Debian, there shouldn't be additional surprises here.
[Original description]
I have a slapd problem on a freshly installed 16.04 machine:
slapd[17107]: segfault at 1a ip 00007f3c12c79f55 sp 00007f3c03c2d080 error 4 in libsasl2.so.2.0.25[7f3c12c72000+19000]
I'm using the server as Slave LDAP-Server and sync replication with kerberos authentication.
The service either starts and runs successfully or it fails with segmentation fault or 100% CPU.
Maybe an useful info, I'm replicating two databases. When I deactivate syncrepl for one of them (doesn't matter which one) the problem is not occuring.
Linux xxx 4.4.0-75-generic #96-Ubuntu SMP Thu Apr 20 09:56:33 UTC 2017 x86_64 x86_64 x86_64 GNU/Linux
slapd 2.4.42+dfsg-2ubuntu3.1
libsasl2-2:amd64 2.1.26.dfsg1-14build1
libsasl2-modules:amd64 2.1.26.dfsg1-14build1
libsasl2-modules-gssapi-mit:amd64 2.1.26.dfsg1-14build1
GDB debug:
Starting program: /usr/sbin/slapd -h "ldap:/// ldaps:/// ldapi:///" -u openldap -g openldap -f /etc/ldap/slapd.conf -d 256
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
590c82ab @(#) $OpenLDAP: slapd (Ubuntu) (May 11 2016 16:12:05) $
buildd@lgw01-10:/build/openldap-mF7Kfq/openldap-2.4.42+dfsg/debian/build/servers/slapd
590c82ab slapd starting
[New Thread 0x7f2e96b7b700 (LWP 42139)]
[New Thread 0x7f2e9637a700 (LWP 42140)]
[New Thread 0x7f2e95b79700 (LWP 42141)]
[New Thread 0x7f2e95378700 (LWP 42142)]
[New Thread 0x7f2e94b77700 (LWP 42143)]
590c82ba slap_client_connect: URI=ldap://xxx ldap_sasl_interactive_bind_s failed (-6)
590c82ba do_syncrepl: rid=132 rc -6 retrying (9 retries left)
Thread 4 "slapd" received signal SIGSEGV, Segmentation fault.
[Switching to Thread 0x7f2e95b79700 (LWP 42141)]
0x00007f2ea53035b5 in sasl_client_add_plugin () from /usr/lib/x86_64-linux-gnu/libsasl2.so.2
(gdb) thr apply all bt
Thread 6 (Thread 0x7f2e94b77700 (LWP 42143)):
#0 pthread_cond_wait@@GLIBC_2.3.2 () at ../sysdeps/unix/sysv/linux/x86_64/pthread_cond_wait.S:185
#1 0x00007f2ea59463f3 in ?? () from /usr/lib/x86_64-linux-gnu/libldap_r-2.4.so.2
#2 0x00007f2ea487c6ba in start_thread (arg=0x7f2e94b77700) at pthread_create.c:333
#3 0x00007f2ea45b282d in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:109
Thread 5 (Thread 0x7f2e95378700 (LWP 42142)):
#0 pthread_cond_wait@@GLIBC_2.3.2 () at ../sysdeps/unix/sysv/linux/x86_64/pthread_cond_wait.S:185
#1 0x00007f2ea59463f3 in ?? () from /usr/lib/x86_64-linux-gnu/libldap_r-2.4.so.2
#2 0x00007f2ea487c6ba in start_thread (arg=0x7f2e95378700) at pthread_create.c:333
#3 0x00007f2ea45b282d in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:109
Thread 4 (Thread 0x7f2e95b79700 (LWP 42141)):
#0 0x00007f2ea53035b5 in sasl_client_add_plugin () from /usr/lib/x86_64-linux-gnu/libsasl2.so.2
#1 0x00007f2ea530f250 in ?? () from /usr/lib/x86_64-linux-gnu/libsasl2.so.2
#2 0x00007f2ea5303d69 in sasl_client_init () from /usr/lib/x86_64-linux-gnu/libsasl2.so.2
#3 0x00007f2ea594da6c in ldap_int_sasl_init () from /usr/lib/x86_64-linux-gnu/libldap_r-2.4.so.2
#4 0x00007f2ea594db2c in ldap_int_sasl_open () from /usr/lib/x86_64-linux-gnu/libldap_r-2.4.so.2
#5 0x00007f2ea594e2d4 in ldap_int_sasl_bind () from /usr/lib/x86_64-linux-gnu/libldap_r-2.4.so.2
#6 0x00007f2ea5951828 in ldap_sasl_interactive_bind () from /usr/lib/x86_64-linux-gnu/libldap_r-2.4.so.2
#7 0x00007f2ea5951a4e in ldap_sasl_interactive_bind_s () from /usr/lib/x86_64-linux-gnu/libldap_r-2.4.so.2
#8 0x0000561fbc556db4 in slap_client_connect (ldp=0x561fbe1e9f68, sb=0x561fbe1e9d40) at ../../../../servers/slapd/config.c:2063
#9 0x0000561fbc5c699d in do_syncrep1 (si=0x561fbe1e9d10, op=0x7f2e95b787b0) at ../../../../servers/slapd/syncrepl.c:618
#10 do_syncrepl (ctx=<optimized out>, arg=0x561fbe1e5620) at ../../../../servers/slapd/syncrepl.c:1548
#11 0x00007f2ea59463a2 in ?? () from /usr/lib/x86_64-linux-gnu/libldap_r-2.4.so.2
#12 0x00007f2ea487c6ba in start_thread (arg=0x7f2e95b79700) at pthread_create.c:333
#13 0x00007f2ea45b282d in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:109
Thread 3 (Thread 0x7f2e9637a700 (LWP 42140)):
---Type <return> to continue, or q <return> to quit---
#0 pthread_cond_wait@@GLIBC_2.3.2 () at ../sysdeps/unix/sysv/linux/x86_64/pthread_cond_wait.S:185
#1 0x00007f2ea59463f3 in ?? () from /usr/lib/x86_64-linux-gnu/libldap_r-2.4.so.2
#2 0x00007f2ea487c6ba in start_thread (arg=0x7f2e9637a700) at pthread_create.c:333
#3 0x00007f2ea45b282d in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:109
Thread 2 (Thread 0x7f2e96b7b700 (LWP 42139)):
#0 0x00007f2ea45b2e23 in epoll_wait () at ../sysdeps/unix/syscall-template.S:84
#1 0x0000561fbc55a8f0 in slapd_daemon_task (ptr=<optimized out>) at ../../../../servers/slapd/daemon.c:2539
#2 0x00007f2ea487c6ba in start_thread (arg=0x7f2e96b7b700) at pthread_create.c:333
#3 0x00007f2ea45b282d in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:109
Thread 1 (Thread 0x7f2ea5d96740 (LWP 42138)):
#0 0x00007f2ea487d98d in pthread_join (threadid=139838073845504, thread_return=0x0) at pthread_join.c:90
#1 0x0000561fbc55cc81 in slapd_daemon () at ../../../../servers/slapd/daemon.c:2932
#2 0x0000561fbc543bea in main (argc=11, argv=<optimized out>) at ../../../../servers/slapd/main.c:1017
(gdb) |
[Impact]
Concurrent SASL authentications could trigger a segfault. This was observed by the bug reporter during replication from a master to a slave, and can be reproduced with a test program.
The fix is applied upstream, see comment #13.
[Test Case]
* Create a fresh xenial VM or container and login. Update the apt repositories:
sudo apt update
* Create a local directory and cd into it:
mkdir test && cd test
* Download the test attachments from this bug: Makefile, sasltest.c and testscript:
wget https://bugs.launchpad.net/ubuntu/+source/openldap/+bug/1688575/+attachment/5139678/+files/Makefile https://bugs.launchpad.net/ubuntu/+source/openldap/+bug/1688575/+attachment/5139679/+files/sasltest.c https://bugs.launchpad.net/ubuntu/+source/openldap/+bug/1688575/+attachment/5139680/+files/testscript
* Build with
$ apt install libsasl2-dev libldap2-dev
$ make
* Execute the testscript with sudo once. It shall fail at the very end with a core dump:
sudo sh ./testscript
(...)
sasltest: sasltest.c:70: bind_thread: Assertion `rc == LDAP_SUCCESS' failed.
Aborted (core dumped)
* Export this var:
export LDAPSASL_SECPROPS=none
* Run the actual test script a few more times to confirm the crasH:
$ ./sasltest
rc = -6 (Unknown authentication method)
sasltest: sasltest.c:70: bind_thread: Assertion `rc == LDAP_SUCCESS' failed.
rc = -6 (Unknown authentication method)
sasltest: sasltest.c:70: bind_thread: Assertion `rc == LDAP_SUCCESS' failed.
rc = -6 (Unknown authentication method)
sasltest: sasltest.c:70: bind_thread: Assertion `rc == LDAP_SUCCESS' failed.
Aborted (core dumped)
* Install the updated packages from proposed
* Run ./sasltest again. Make sure the LDAPSASL_SECPROPS var is still exported:
$ echo $LDAPSASL_SECPROPS
none
$ ./sasltest
$
This time the test completes without crashing.
[Regression Potential]
This is SASL authentication, and with kerberos nonetheless (in the case of the bug reporter). I suspect not many people deploy this due to its complexity. The ones that have such a setup, however, tend to know what they are doing, so if they say the problem is fixed for them, I believe it is.
About this particular change, it's committed upstream and also in debian, and @rtandy was kind enough to provide a sample test script that exhibits the problem.
[Other Info]
Since the fix is applied upstream and in Debian, there shouldn't be additional surprises here.
[Original description]
I have a slapd problem on a freshly installed 16.04 machine:
slapd[17107]: segfault at 1a ip 00007f3c12c79f55 sp 00007f3c03c2d080 error 4 in libsasl2.so.2.0.25[7f3c12c72000+19000]
I'm using the server as Slave LDAP-Server and sync replication with kerberos authentication.
The service either starts and runs successfully or it fails with segmentation fault or 100% CPU.
Maybe an useful info, I'm replicating two databases. When I deactivate syncrepl for one of them (doesn't matter which one) the problem is not occuring.
Linux xxx 4.4.0-75-generic #96-Ubuntu SMP Thu Apr 20 09:56:33 UTC 2017 x86_64 x86_64 x86_64 GNU/Linux
slapd 2.4.42+dfsg-2ubuntu3.1
libsasl2-2:amd64 2.1.26.dfsg1-14build1
libsasl2-modules:amd64 2.1.26.dfsg1-14build1
libsasl2-modules-gssapi-mit:amd64 2.1.26.dfsg1-14build1
GDB debug:
Starting program: /usr/sbin/slapd -h "ldap:/// ldaps:/// ldapi:///" -u openldap -g openldap -f /etc/ldap/slapd.conf -d 256
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
590c82ab @(#) $OpenLDAP: slapd (Ubuntu) (May 11 2016 16:12:05) $
buildd@lgw01-10:/build/openldap-mF7Kfq/openldap-2.4.42+dfsg/debian/build/servers/slapd
590c82ab slapd starting
[New Thread 0x7f2e96b7b700 (LWP 42139)]
[New Thread 0x7f2e9637a700 (LWP 42140)]
[New Thread 0x7f2e95b79700 (LWP 42141)]
[New Thread 0x7f2e95378700 (LWP 42142)]
[New Thread 0x7f2e94b77700 (LWP 42143)]
590c82ba slap_client_connect: URI=ldap://xxx ldap_sasl_interactive_bind_s failed (-6)
590c82ba do_syncrepl: rid=132 rc -6 retrying (9 retries left)
Thread 4 "slapd" received signal SIGSEGV, Segmentation fault.
[Switching to Thread 0x7f2e95b79700 (LWP 42141)]
0x00007f2ea53035b5 in sasl_client_add_plugin () from /usr/lib/x86_64-linux-gnu/libsasl2.so.2
(gdb) thr apply all bt
Thread 6 (Thread 0x7f2e94b77700 (LWP 42143)):
#0 pthread_cond_wait@@GLIBC_2.3.2 () at ../sysdeps/unix/sysv/linux/x86_64/pthread_cond_wait.S:185
#1 0x00007f2ea59463f3 in ?? () from /usr/lib/x86_64-linux-gnu/libldap_r-2.4.so.2
#2 0x00007f2ea487c6ba in start_thread (arg=0x7f2e94b77700) at pthread_create.c:333
#3 0x00007f2ea45b282d in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:109
Thread 5 (Thread 0x7f2e95378700 (LWP 42142)):
#0 pthread_cond_wait@@GLIBC_2.3.2 () at ../sysdeps/unix/sysv/linux/x86_64/pthread_cond_wait.S:185
#1 0x00007f2ea59463f3 in ?? () from /usr/lib/x86_64-linux-gnu/libldap_r-2.4.so.2
#2 0x00007f2ea487c6ba in start_thread (arg=0x7f2e95378700) at pthread_create.c:333
#3 0x00007f2ea45b282d in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:109
Thread 4 (Thread 0x7f2e95b79700 (LWP 42141)):
#0 0x00007f2ea53035b5 in sasl_client_add_plugin () from /usr/lib/x86_64-linux-gnu/libsasl2.so.2
#1 0x00007f2ea530f250 in ?? () from /usr/lib/x86_64-linux-gnu/libsasl2.so.2
#2 0x00007f2ea5303d69 in sasl_client_init () from /usr/lib/x86_64-linux-gnu/libsasl2.so.2
#3 0x00007f2ea594da6c in ldap_int_sasl_init () from /usr/lib/x86_64-linux-gnu/libldap_r-2.4.so.2
#4 0x00007f2ea594db2c in ldap_int_sasl_open () from /usr/lib/x86_64-linux-gnu/libldap_r-2.4.so.2
#5 0x00007f2ea594e2d4 in ldap_int_sasl_bind () from /usr/lib/x86_64-linux-gnu/libldap_r-2.4.so.2
#6 0x00007f2ea5951828 in ldap_sasl_interactive_bind () from /usr/lib/x86_64-linux-gnu/libldap_r-2.4.so.2
#7 0x00007f2ea5951a4e in ldap_sasl_interactive_bind_s () from /usr/lib/x86_64-linux-gnu/libldap_r-2.4.so.2
#8 0x0000561fbc556db4 in slap_client_connect (ldp=0x561fbe1e9f68, sb=0x561fbe1e9d40) at ../../../../servers/slapd/config.c:2063
#9 0x0000561fbc5c699d in do_syncrep1 (si=0x561fbe1e9d10, op=0x7f2e95b787b0) at ../../../../servers/slapd/syncrepl.c:618
#10 do_syncrepl (ctx=<optimized out>, arg=0x561fbe1e5620) at ../../../../servers/slapd/syncrepl.c:1548
#11 0x00007f2ea59463a2 in ?? () from /usr/lib/x86_64-linux-gnu/libldap_r-2.4.so.2
#12 0x00007f2ea487c6ba in start_thread (arg=0x7f2e95b79700) at pthread_create.c:333
#13 0x00007f2ea45b282d in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:109
Thread 3 (Thread 0x7f2e9637a700 (LWP 42140)):
---Type <return> to continue, or q <return> to quit---
#0 pthread_cond_wait@@GLIBC_2.3.2 () at ../sysdeps/unix/sysv/linux/x86_64/pthread_cond_wait.S:185
#1 0x00007f2ea59463f3 in ?? () from /usr/lib/x86_64-linux-gnu/libldap_r-2.4.so.2
#2 0x00007f2ea487c6ba in start_thread (arg=0x7f2e9637a700) at pthread_create.c:333
#3 0x00007f2ea45b282d in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:109
Thread 2 (Thread 0x7f2e96b7b700 (LWP 42139)):
#0 0x00007f2ea45b2e23 in epoll_wait () at ../sysdeps/unix/syscall-template.S:84
#1 0x0000561fbc55a8f0 in slapd_daemon_task (ptr=<optimized out>) at ../../../../servers/slapd/daemon.c:2539
#2 0x00007f2ea487c6ba in start_thread (arg=0x7f2e96b7b700) at pthread_create.c:333
#3 0x00007f2ea45b282d in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:109
Thread 1 (Thread 0x7f2ea5d96740 (LWP 42138)):
#0 0x00007f2ea487d98d in pthread_join (threadid=139838073845504, thread_return=0x0) at pthread_join.c:90
#1 0x0000561fbc55cc81 in slapd_daemon () at ../../../../servers/slapd/daemon.c:2932
#2 0x0000561fbc543bea in main (argc=11, argv=<optimized out>) at ../../../../servers/slapd/main.c:1017
(gdb) |
|
| 2018-05-24 20:05:06 |
Brian Murray |
openldap (Ubuntu Xenial): status |
In Progress |
Fix Committed |
|
| 2018-05-24 20:05:09 |
Brian Murray |
bug |
|
|
added subscriber Ubuntu Stable Release Updates Team |
| 2018-05-24 20:05:10 |
Brian Murray |
bug |
|
|
added subscriber SRU Verification |
| 2018-05-24 20:05:14 |
Brian Murray |
tags |
patch server-next |
patch server-next verification-needed verification-needed-xenial |
|
| 2018-06-05 07:58:40 |
Suho Meso |
tags |
patch server-next verification-needed verification-needed-xenial |
patch server-next verification-done-xenial verification-needed |
|
| 2018-06-06 10:23:41 |
Robie Basak |
removed subscriber Ubuntu Stable Release Updates Team |
|
|
|
| 2018-06-06 10:23:40 |
Launchpad Janitor |
openldap (Ubuntu Xenial): status |
Fix Committed |
Fix Released |
|
| 2022-06-13 18:23:01 |
Launchpad Janitor |
merge proposal linked |
|
https://code.launchpad.net/~sergiodj/ubuntu/+source/openldap/+git/openldap/+merge/424341 |
|
| 2022-06-13 19:08:48 |
Launchpad Janitor |
merge proposal unlinked |
https://code.launchpad.net/~sergiodj/ubuntu/+source/openldap/+git/openldap/+merge/424341 |
|
|
