OpenLDAP (slapd) is broken in Ubuntu 22.04 after upgrade to version 2.5.17+dfsg-0ubuntu0.22.04.1

[Viva Brock]

In Ubuntu 22.04, OpenLDAP (slapd) is broken after upgrade to version 2.5.17+dfsg-0ubuntu0.22.04.1 from version 2.5.16+dfsg-0ubuntu0.22.04.2. I have a snapshot of the system immediately before the upgrade of OpenLDAP, and with version 2.5.16+dfsg-0ubuntu0.22.04.2 everything is working perfectly fine. Then, after upgrade of OpenLDAP (slapd) from 2.5.16+dfsg-0ubuntu0.22.04.2 to version 2.5.17+dfsg-0ubuntu0.22.04.1 the "slapd" will crash immediately at startup with a "segmentation fault". Since nothing else on the system was changed, it is 100% evident that OpenLDAP 2.5.17+dfsg-0ubuntu0.22.04.1 is broken and, at the moment, this can only be fixed by reverting to version 2.5.16+dfsg-0ubuntu0.22.04.2. Indeed, if I revert to the snapshot just before the OpenLDAP (slapd), everything is working again. Again, nothing else except for OpenLDAP (slapd) changes on the system.

To reproduce the crash, it is sufficient to just upgrade OpenLDAP (slapd) to version 2.5.17+dfsg-0ubuntu0.22.04.1 and then just run " /usr/sbin/slapd". It will crash right away!

For evidence, here is stack trace:

Starting program: /usr/sbin/slapd
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
Program received signal SIGSEGV, Segmentation fault.
__strlen_evex () at ../sysdeps/x86_64/multiarch/strlen-evex.S:77
77 ../sysdeps/x86_64/multiarch/strlen-evex.S: Datei oder Verzeichnis nicht gefunden.
(gdb) backtrace
#0 __strlen_evex () at ../sysdeps/x86_64/multiarch/strlen-evex.S:77
#1 0x00007f32b3287489 in ber_strdup_x () from /lib/x86_64-linux-gnu/liblber-2.5.so.0
#2 0x00007f32b32c4b07 in ldap_charray_dup () from /lib/x86_64-linux-gnu/libldap-2.5.so.0
#3 0x00007f32b3220566 in slapi_int_read_config () from /lib/x86_64-linux-gnu/libslapi-2.5.so.0
#4 0x000055579bcb403f in ?? ()
#5 0x000055579bcbea03 in config_set_vals ()
#6 0x000055579bcc65c5 in config_parse_add ()
#7 0x000055579bcbceba in ?? ()
#8 0x000055579bcbde0b in ?? ()
#9 0x000055579bcdc738 in ?? ()
#10 0x000055579bce6ae8 in slap_send_search_entry ()
#11 0x000055579bd5f941 in ?? ()
#12 0x000055579bd5f9dd in ?? ()
#13 0x000055579bd60866 in ?? ()
#14 0x000055579bd608a0 in ?? ()
#15 0x000055579bcbad31 in ?? ()
#16 0x000055579bcbb05b in read_config ()
#17 0x000055579bcb0063 in main ()

[Paride Legovini (paride)]

Hello and thank you for reporting this bug. Let me confirm that I have understood your steps correctly:

* You had a Jammy system running slapd version 2.5.16+dfsg-0ubuntu0, and it was working fine.

* You upgraded the system, which included updating several packages, including slapd (to version 2.5.17+dfsg-0ubuntu0.22.04.1, indicating that you have jammy-updates enabled).

* After the upgrade, you noticed the crash. You rolled back to the pre-upgrade snapshot, and everything worked fine again.

* You then tried updating *only* slapd (using `apt update` and `apt install slapd`), and it started crashing again. Therefore, you deduce that the problem is with slapd.

Is this correct?

There is a new version of slapd available in jammy-proposed. Can you please try installing it and check if the crash still occurs? For instructions on how to enable -proposed and selectively install packages from it, please see this guide.

I tried to reproduce your issue by installing slapd 2.5.17+dfsg-0ubuntu0.22.04.1 and running /usr/sbin/slapd, but it did not crash for me. This version of slapd was released to jammy-updates in March 2024, so it is unlikely to be an issue affecting the most common configurations.

[1] https://wiki.ubuntu.com/Testing/EnableProposed

[Viva Brock (houst1947)]

Yes, I have a Ubuntu 22.04 (Jammy) system where "slapd" at version 2.5.16+dfsg-0ubuntu0.22.04.2 is running perfectly fine. Has been running for 1+ year without problems (ever since I upgraded from Ubuntu 20.04).

Now, I have a snapshot where all packages, except for "slapd", "libldap" and "ldap-utils", have been upgraded to the latest available version. At this point, everything is still fine. But, if I upgrade the "slapd" package (including "libldap" and "ldap-utils") to the latest version too, i.e. version 2.5.17+dfsg-0ubuntu0.22.04.1, then it will start to crash! Reverting to the snapshot fixes this problem.

So, yes, its definitely that "slapd" version is the last good version 2.5.16+dfsg-0ubuntu0.22.04.2, whereas version 2.5.17+dfsg-0ubuntu0.22.04.1 is broken. I did *not* change anything else, except for upgrading "slapd" via APT, so this definitely is *not* related to any changes to my configuration etc.!

(the stack trace would indicate that slapd crashes while reading the configuration at startup)

Okay, I will try with the "jammy-proposed" version soon...

[Sergio Durigan Junior (sergiodj)]

Thank you for the feedback, Viva.

As Paride mentioned, the first thing to do here is verify whether the new OpenLDAP from jammy-proposed solves the issue.

If it doesn't work, then we will need to work on a reproducer for the problem. But let's cross that bridge if and when we get there. Meanwhile, I am hopeful that this new upstream release will fix the crash you're seeing.

Thanks.

[Viva Brock (houst1947)]

I can now confirm that "slapd" version 2.5.18+dfsg-0ubuntu0.22.04.1 (from jammy-proposed) does indeed work!

$ /usr/sbin/slapd -VV
@(#) $OpenLDAP: slapd 2.5.18+dfsg-0ubuntu0.22.04.1 (May 31 2024 15:01:55) $
        Ubuntu Developers <email address hidden>

$ sudo systemctl status slapd
● slapd.service - LSB: OpenLDAP standalone server (Lightweight Directory Access Protocol)
     Loaded: loaded (/etc/init.d/slapd; generated)
    Drop-In: /usr/lib/systemd/system/slapd.service.d
             └─slapd-remain-after-exit.conf
     Active: active (running) since Thu 2024-07-04 20:27:46 CEST; 2min 9s ago
       Docs: man:systemd-sysv-generator(8)
      Tasks: 4 (limit: 4559)
     Memory: 22.3M
        CPU: 528ms
     CGroup: /system.slice/slapd.service
             └─3928 /usr/sbin/slapd -h "ldap:/// ldapi:/// ldaps:///" -g openldap -u openldap -F /etc/ldap/slapd.d

[Sergio Durigan Junior (sergiodj)]

That's great, thanks for confirming that the new version works.

I have just verified it, which means that it will take around 7 days for the new package to reach the jammy-updates pocket. Once it does, I will mark this bug as Fix Released.