Hi!
At work I have to connect to our SLES servers via Windows RDP and a Windows server. Unfortunately RDP is not working reliably, and it sometimes misses key presses, and at other times it duplicates them. That way I ended up adding an olcAuthzRegexp that lacked a backspace. Unfrtunately when trying to ldapmodify the server I just got: modifying entry "cn=config" ldap_result: Can't contact LDAP server (-1)
the regex in question is: olcAuthzRegexp: {3} "^dn:dnQualifier=uid\3D(^,)\2Cou\3Dpeople\2Cdc\3DXXX \2Cdc\3Dde$" "dn: uid=$1,ou=people,dc=XXX=de"
As it turned out the server dumped core (100% reproducible). I know the regex is bad, but maybe it shouldn’t kill the server. The server is SUSE’s version that corresponds to some 2.5.x with patches. Anyway the backtrace is:
Mar 17 14:36:23 v05 slapd[15911]: conn=1000 op=1 syncprov_matchops: recording uuid for dn=cn=config on opc=0x7fcfe0000d58 Mar 17 14:36:23 v05 slapd[15911]: slap_get_csn: conn=1000 op=1 generated new csn=20250317133623.651964Z#000000#005#000000 manage=1 Mar 17 14:36:23 v05 slapd[15911]: slap_queue_csn: queueing 0x7fcfe0106c70 20250317133623.651964Z#000000#005#000000 Mar 17 14:36:23 v05 kernel: slapd[15919]: segfault at 7fc81ceea633 ip 00007fcff658553e sp 00007fcfe9ff4e40 error 4 in libldap-2.5.releng.so.0.1.13[7fcff653b000+5c000] likely on CPU 1 (core 0, socket 2) Mar 17 14:36:23 v05 kernel: Code: 7f 08 4d 85 ff 75 9e 48 83 c4 18 b8 fa ff ff ff 5b 5d 41 5c 41 5d 41 5e 41 5f c3 90 48 85 ff 74 3b 41 54 55 31 ed 53 48 89 fb <48> 8b 7f 08 49 89 f4 48 85 ff 75 3e 48 8b 7b 10 48 85 ff 75 25 4d … Mar 17 14:36:23 v05 systemd[1]: Started Process Core Dump (PID 15922/UID 0). Mar 17 14:36:23 v05 systemd-coredump[15923]: [🡕] Process 15911 (slapd) of user 1000 dumped core.
Stack trace of thread 15919: #0 0x00007fcff658553e ldap_avl_free (libldap-2.5.releng.so.0 + 0x4a53e) #1 0x0000555fb6ca9b42 rewrite_info_delete (slapd + 0xd6b42) #2 0x0000555fb6c64bae slap_sasl_regexp_config (slapd + 0x91bae) #3 0x0000555fb6c03a09 n/a (slapd + 0x30a09) #4 0x0000555fb6c091d3 config_set_vals (slapd + 0x361d3) #5 0x0000555fb6c0a14f config_parse_add (slapd + 0x3714f) #6 0x0000555fb6bfcdcc n/a (slapd + 0x29dcc) #7 0x0000555fb6bfdc96 n/a (slapd + 0x2ac96) #8 0x0000555fb6c8a523 overlay_op_walk (slapd + 0xb7523) #9 0x0000555fb6c8a6ae n/a (slapd + 0xb76ae) #10 0x0000555fb6c2dbd2 fe_op_modify (slapd + 0x5abd2) #11 0x0000555fb6c2f941 do_modify (slapd + 0x5c941) #12 0x0000555fb6c1618f n/a (slapd + 0x4318f) #13 0x0000555fb6c1698d n/a (slapd + 0x4398d) #14 0x00007fcff6583da0 n/a (libldap-2.5.releng.so.0 + 0x48da0) #15 0x00007fcff62a758c start_thread (libc.so.6 + 0xa758c) #16 0x00007fcff632ea28 __clone3 (libc.so.6 + 0x12ea28)
Stack trace of thread 15915: #0 0x00007fcff62a3c4e __futex_abstimed_wait_common (libc.so.6 + 0xa3c4e) #1 0x00007fcff62a6890 pthread_cond_wait@@GLIBC_2.3.2 (libc.so.6 + 0xa6890) #2 0x00007fcff6583e40 n/a (libldap-2.5.releng.so.0 + 0x48e40) #3 0x00007fcff62a758c start_thread (libc.so.6 + 0xa758c) #4 0x00007fcff632ea28 __clone3 (libc.so.6 + 0x12ea28)
Stack trace of thread 15917: #0 0x00007fcff62a3c4e __futex_abstimed_wait_common (libc.so.6 + 0xa3c4e) #1 0x00007fcff62a6890 pthread_cond_wait@@GLIBC_2.3.2 (libc.so.6 + 0xa6890) #2 0x00007fcff6583e40 n/a (libldap-2.5.releng.so.0 + 0x48e40) #3 0x00007fcff62a758c start_thread (libc.so.6 + 0xa758c) #4 0x00007fcff632ea28 __clone3 (libc.so.6 + 0x12ea28)
Stack trace of thread 15911: #0 0x00007fcff62a3c4e __futex_abstimed_wait_common (libc.so.6 + 0xa3c4e) #1 0x00007fcff62a91a3 __pthread_clockjoin_ex (libc.so.6 + 0xa91a3) #2 0x0000555fb6c131ca slapd_daemon (slapd + 0x401ca) #3 0x0000555fb6bf688e main (slapd + 0x2388e) #4 0x00007fcff6240e6c __libc_start_call_main (libc.so.6 + 0x40e6c) #5 0x00007fcff6240f35 __libc_start_main@@GLIBC_2.34 (libc.so.6 + 0x40f35) #6 0x0000555fb6bf690a _start (slapd + 0x2390a)
Stack trace of thread 15913: #0 0x00007fcff632ee86 epoll_wait (libc.so.6 + 0x12ee86) #1 0x0000555fb6c1007b n/a (slapd + 0x3d07b) #2 0x00007fcff62a758c start_thread (libc.so.6 + 0xa758c) #3 0x00007fcff632ea28 __clone3 (libc.so.6 + 0x12ea28)
Stack trace of thread 15918: #0 0x00007fcff62a3c4e __futex_abstimed_wait_common (libc.so.6 + 0xa3c4e) #1 0x00007fcff62a6890 pthread_cond_wait@@GLIBC_2.3.2 (libc.so.6 + 0xa6890) #2 0x00007fcff6583e40 n/a (libldap-2.5.releng.so.0 + 0x48e40) #3 0x00007fcff62a758c start_thread (libc.so.6 + 0xa758c) #4 0x00007fcff632ea28 __clone3 (libc.so.6 + 0x12ea28)
Stack trace of thread 15914: #0 0x00007fcff62a3c4e __futex_abstimed_wait_common (libc.so.6 + 0xa3c4e) #1 0x00007fcff62a6890 pthread_cond_wait@@GLIBC_2.3.2 (libc.so.6 + 0xa6890) #2 0x00007fcff6583e40 n/a (libldap-2.5.releng.so.0 + 0x48e40) #3 0x00007fcff62a758c start_thread (libc.so.6 + 0xa758c) #4 0x00007fcff632ea28 __clone3 (libc.so.6 + 0x12ea28) ELF object binary architecture: AMD x86-64 Mar 17 14:36:23 v05 ldapmodify[15921]: DIGEST-MD5 common mech free Mar 17 14:36:23 v05 systemd[1]: slapd.service: Main process exited, code=dumped, status=11/SEGV Mar 17 14:36:23 v05 systemd[1]: slapd.service: Failed with result 'core-dump'. Mar 17 14:36:23 v05 systemd[1]: systemd-coredump@3-15922-0.service: Deactivated successfully.
Kind regards, Ulrich Windl
--On Monday, March 17, 2025 2:49 PM +0000 "Windl, Ulrich" u.windl@ukr.de wrote:
Hi!
At work I have to connect to our SLES servers via Windows RDP and a Windows server. Unfortunately RDP is not working reliably, and it sometimes misses key presses, and at other times it duplicates them. That way I ended up adding an olcAuthzRegexp that lacked a backspace.
Please file this as an ITS: https://bugs.openldap.org
--Quanah
openldap-technical@openldap.org