https://bugs.openldap.org/show_bug.cgi?id=10320
Issue ID: 10320 Summary: sigsegv in autogroup Product: OpenLDAP Version: 2.6.9 Hardware: x86_64 OS: Linux Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: overlays Assignee: bugs@openldap.org Reporter: sergej+openldap@p5n.pp.ru Target Milestone: ---
slapd crashes in autogroup overlay on group modification
I have few coredumps and can provide more information. This fails on 0x23 address, it may differs but it looks like f->f_un.f_un_complex is not ended with NULL sometimes.
Modified group here is not autogroup, just groupOfUniqueNames. Operation is adding uniqueMember.
Distro: Archlinux
Overlay config: overlay autogroup autogroup-attrset labeledURIObject labeledURI uniqueMember autogroup-memberof-ad memberOf
Stack: #0 0x00007e77bf511d7c in autogroup_memberOf_filter (f=f@entry=0x6f2c6d6165742d70, dn=dn@entry=0x7e765c1659f8, memberof_ad=memberof_ad@entry=0x5ac9490c2190) at autogroup.c:1532 #1 0x00007e77bf511dd1 in autogroup_memberOf_filter (f=0x6f2c6d6165742d70, f@entry=0x5ac9495089f0, dn=dn@entry=0x7e765c1659f8, memberof_ad=memberof_ad@entry=0x5ac9490c2190) at autogroup.c:1537 #2 0x00007e77bf511dd1 in autogroup_memberOf_filter (f=0x5ac9495089f0, dn=dn@entry=0x7e765c1659f8, memberof_ad=0x5ac9490c2190) at autogroup.c:1537 #3 0x00007e77bf512538 in autogroup_modify_entry (op=<optimized out>, rs=0x7e7665cf9910) at autogroup.c:1606 #4 0x00005ac946faf432 in overlay_op_walk () #5 0x00005ac946faf5f2 in ?? () #6 0x00005ac946f494cf in fe_op_modify () #7 0x00005ac946f4b623 in do_modify () #8 0x00005ac946f304d7 in ?? () #9 0x00005ac946f30f4b in ?? () #10 0x00007e77c04756e1 in ldap_int_thread_pool_wrapper (xpool=0x5ac949016bc0) at tpool.c:1059 #11 0x00007e77bfe4b70a in start_thread (arg=<optimized out>) at pthread_create.c:448 #12 0x00007e77bfecfaac in __GI___clone3 () at ../sysdeps/unix/sysv/linux/x86_64/clone3.S:78
(gdb) p *f Cannot access memory at address 0x23
(gdb) up #1 0x000070fe705f3dd1 in autogroup_memberOf_filter (f=0x23, f@entry=0x55d1c45b6310, dn=dn@entry=0x70fd3000c428, memberof_ad=memberof_ad@entry=0x55d1c416a300) at autogroup.c:1537 1537 result = result || autogroup_memberOf_filter( f, dn, memberof_ad );
(gdb) up #2 0x000070fe705f3dd1 in autogroup_memberOf_filter (f=0x55d1c45b6310, f@entry=0x55d1c45b6670, dn=dn@entry=0x70fd3000c428, memberof_ad=memberof_ad@entry=0x55d1c416a300) at autogroup.c:1537 1537 result = result || autogroup_memberOf_filter( f, dn, memberof_ad );
(gdb) p *f->f_un.f_un_complex $5 = {f_choice = 124232868587560, f_un = {f_un_result = 939550768, f_un_desc = 0x70fd38006830, f_un_ava = 0x70fd38006830, f_un_ssa = 0x70fd38006830, f_un_mra = 0x70fd38006830, f_un_complex = 0x70fd38006830}, f_next = 0x23}
f_next is 0x23 which is bad address
https://bugs.openldap.org/show_bug.cgi?id=10320
--- Comment #1 from sergej sergej+openldap@p5n.pp.ru --- It can be reproduced quite easy on massive groupOfUniqueNames modification, when I try to add user to several group by preparing file with modifications and run `ldapmodify` command.
Obviously no autogroups included directly in these modifications but there are some autogroups that depends on new membership in these modifications.
https://bugs.openldap.org/show_bug.cgi?id=10320
--- Comment #2 from Ondřej Kuzník ondra@mistotebe.net --- On Tue, Mar 18, 2025 at 12:16:52PM +0000, openldap-its@openldap.org wrote:
It can be reproduced quite easy on massive groupOfUniqueNames modification, when I try to add user to several group by preparing file with modifications and run `ldapmodify` command.
Obviously no autogroups included directly in these modifications but there are some autogroups that depends on new membership in these modifications.
Hi Sergej, I'm struggling to figure out how to set up the same situation you're describing, would you be able to provide a sample configuration plus data to reproduce?
Thanks,
https://bugs.openldap.org/show_bug.cgi?id=10320
--- Comment #3 from sergej@p5n.pp.ru --- Created attachment 1058 --> https://bugs.openldap.org/attachment.cgi?id=1058&action=edit archive with config and db dump
https://bugs.openldap.org/show_bug.cgi?id=10320
--- Comment #4 from sergej@p5n.pp.ru --- Steps to reproduce (for Archlinux):
put configs to /etc/openldap/
$ rm -f /var/lib/openldap/openldap-data/* $ slapadd -l test/dump.ldif $ /usr/lib/slapd -d 0 -h "ldap:/// ldapi:///"
$ ldapmodify -c -D "cn=root,dc=root" -w 123123 -f test/ldap-groups-add.ldif $ ldapmodify -c -D "cn=root,dc=root" -w 123123 -f test/ldap-groups-delete.ldif
usually it crashes on first ldapmodify
https://bugs.openldap.org/show_bug.cgi?id=10320
Howard Chu hyc@openldap.org changed:
What |Removed |Added ---------------------------------------------------------------------------- Ever confirmed|0 |1 Status|UNCONFIRMED |IN_PROGRESS
--- Comment #5 from Howard Chu hyc@openldap.org --- I get a different result from what you initially posted
67ec140f.2d418fe1 0x7ffef4a00640 ==> autogroup_delete_member_from_group removing all members from <cn=group9f2db903,ou=groups,dc=root> 67ec140f.2d41a457 0x7ffef4a00640 => mdb_search 67ec140f.2d41b6e5 0x7ffef4a00640 mdb_dn2entry("cn=group9f2db903,ou=groups,dc=root") 67ec140f.2d41c3b7 0x7ffef4a00640 => mdb_dn2id("cn=group9f2db903,ou=groups,dc=root") 67ec140f.2d41d82d 0x7ffef4a00640 <= mdb_dn2id: got id=0x107 67ec140f.2d41e72e 0x7ffef4a00640 => mdb_entry_decode: 67ec140f.2d41f630 0x7ffef4a00640 <= mdb_entry_decode 67ec140f.2d420577 0x7ffef4a00640 base_candidates: base: "cn=group9f2db903,ou=groups,dc=root" (0x00000107) 67ec140f.2d421b90 0x7ffef4a00640 send_ldap_result: conn=1000 op=12 p=3 67ec140f.2d4224d7 0x7ffef4a00640 send_ldap_result: err=0 matched="" text="" 67ec140f.2d42357b 0x7ffef4a00640 => mdb_entry_get: ndn: "cn=group9f2db903,ou=groups,dc=root" 67ec140f.2d4240aa 0x7ffef4a00640 => mdb_entry_get: oc: "(null)", at: "uniqueMember" 67ec140f.2d424b94 0x7ffef4a00640 mdb_dn2entry("cn=group9f2db903,ou=groups,dc=root") 67ec140f.2d4258ad 0x7ffef4a00640 => mdb_dn2id("cn=group9f2db903,ou=groups,dc=root") 67ec140f.2d426b80 0x7ffef4a00640 <= mdb_dn2id: got id=0x107 67ec140f.2d4276f5 0x7ffef4a00640 => mdb_entry_decode: 67ec140f.2d4285f6 0x7ffef4a00640 <= mdb_entry_decode 67ec140f.2d4290e0 0x7ffef4a00640 mdb_entry_get: rc=0 67ec140f.2d42c4b6 0x7ffef4a00640 mdb_modify: cn=group9f2db903,ou=groups,dc=root 67ec140f.2d42cfe5 0x7ffef4a00640 mdb_dn2entry("cn=group9f2db903,ou=groups,dc=root") 67ec140f.2d42d789 0x7ffef4a00640 => mdb_dn2id("cn=group9f2db903,ou=groups,dc=root") 67ec140f.2d42ea5c 0x7ffef4a00640 <= mdb_dn2id: got id=0x107 67ec140f.2d42f7ba 0x7ffef4a00640 => mdb_entry_decode: 67ec140f.2d430676 0x7ffef4a00640 <= mdb_entry_decode 67ec140f.2d43115f 0x7ffef4a00640 mdb_modify_internal: 0x00000107: cn=group9f2db903,ou=groups,dc=root 67ec140f.2d437839 0x7ffef4a00640 mdb_modify_internal: delete uniqueMember 67ec140f.2d43b510 0x7ffef4a00640 oc_check_required entry (cn=group9f2db903,ou=groups,dc=root), objectClass "groupOfUniqueNames" 67ec140f.2d43c228 0x7ffef4a00640 Entry (cn=group9f2db903,ou=groups,dc=root): object class 'groupOfUniqueNames' requires attribute 'uniqueMember' 67ec140f.2d43d313 0x7ffef4a00640 entry failed schema check: object class 'groupOfUniqueNames' requires attribute 'uniqueMember' 67ec140f.2d43de42 0x7ffef4a00640 mdb_modify: modify failed (65) 67ec140f.2d43e9b7 0x7ffef4a00640 send_ldap_result: conn=1000 op=12 p=3 67ec140f.2d43f344 0x7ffef4a00640 send_ldap_result: err=65 matched="" text="object class 'groupOfUniqueNames' requires attribute 'uniqueMember'" 67ec140f.2d44125e 0x7ffef4a00640 ==> autogroup_add_members_from_filter <cn=group9f2db903,ou=groups,dc=root>
Thread 3 "slapd" received signal SIGSEGV, Segmentation fault. [Switching to Thread 0x7ffef4a00640 (LWP 1941088)] 0x00007ffff73e5f00 in nestgroup_filter_instances (op=0x7ffef49fdb90, ad=0x5555558b2ad0, f=0x2000, not=0, nfn=0x7ffef49fd740, nfp=0x7ffef49fd760, negated=0x7ffef49fd744) at ../../../../head/servers/slapd/overlays/nestgroup.c:264 264 switch( f->f_choice & SLAPD_FILTER_MASK ) { (gdb) bt #0 0x00007ffff73e5f00 in nestgroup_filter_instances (op=0x7ffef49fdb90, ad=0x5555558b2ad0, f=0x2000, not=0, nfn=0x7ffef49fd740, nfp=0x7ffef49fd760, negated=0x7ffef49fd744) at ../../../../head/servers/slapd/overlays/nestgroup.c:264 #1 0x00007ffff73e60a4 in nestgroup_filter_instances (op=0x7ffef49fdb90, ad=0x5555558b2ad0, f=0x2000, not=0, nfn=0x7ffef49fd740, nfp=0x7ffef49fd760, negated=0x7ffef49fd744) at ../../../../head/servers/slapd/overlays/nestgroup.c:294 #2 0x00007ffff73e60a4 in nestgroup_filter_instances (op=0x7ffef49fdb90, ad=0x5555558b2ad0, f=0x555555c27750, not=0, nfn=0x7ffef49fd740, nfp=0x7ffef49fd760, negated=0x7ffef49fd744) at ../../../../head/servers/slapd/overlays/nestgroup.c:294 #3 0x00007ffff73e7c23 in nestgroup_op_search (op=0x7ffef49fdb90, rs=0x7ffef49fdb20) at ../../../../head/servers/slapd/overlays/nestgroup.c:734 #4 0x0000555555661451 in overlay_op_walk (op=0x7ffef49fdb90, rs=0x7ffef49fdb20, which=op_search, oi=0x555555887ff0, on=0x5555558b0a80) at ../../../head/servers/slapd/backover.c:691 #5 0x00005555556617c0 in over_op_func (op=0x7ffef49fdb90, rs=0x7ffef49fdb20, which=op_search) at ../../../head/servers/slapd/backover.c:766 #6 0x0000555555661944 in over_op_search (op=0x7ffef49fdb90, rs=0x7ffef49fdb20) at ../../../head/servers/slapd/backover.c:796 #7 0x00007ffff73a4424 in autogroup_add_members_from_filter (op=0x7ffee8002930, e=0x0, age=0x555555c275a0, agf=0x555555c270a0, modify=1) at autogroup.c:552 #8 0x00007ffff73a660c in autogroup_response (op=0x7ffee8002930, rs=0x7ffef49ff990) at autogroup.c:1167 #9 0x00005555556601c8 in over_back_response (op=0x7ffee8002930, rs=0x7ffef49ff990) at ../../../head/servers/slapd/backover.c:245 #10 0x00005555555c91af in slap_response_play (op=0x7ffee8002930, rs=0x7ffef49ff990) at ../../../head/servers/slapd/result.c:573 #11 0x00005555555c942a in send_ldap_response (op=0x7ffee8002930, rs=0x7ffef49ff990) at ../../../head/servers/slapd/result.c:648 #12 0x00005555555ca530 in slap_send_ldap_result (op=0x7ffee8002930, rs=0x7ffef49ff990) at ../../../head/servers/slapd/result.c:924 #13 0x00007ffff72e85c4 in mdb_modify (op=0x7ffee8002930, rs=0x7ffef49ff990) at ../../../../head/servers/slapd/back-mdb/modify.c:803 #14 0x00005555556614f7 in overlay_op_walk (op=0x7ffee8002930, rs=0x7ffef49ff990, which=op_modify, oi=0x555555887ff0, on=0x0) at ../../../head/servers/slapd/backover.c:706 #15 0x00005555556617c0 in over_op_func (op=0x7ffee8002930, rs=0x7ffef49ff990, which=op_modify) at ../../../head/servers/slapd/backover.c:766 #16 0x00005555556619a0 in over_op_modify (op=0x7ffee8002930, rs=0x7ffef49ff990) at ../../../head/servers/slapd/backover.c:808 #17 0x00005555555d4987 in fe_op_modify (op=0x7ffee8002930, rs=0x7ffef49ff990) at ../../../head/servers/slapd/modify.c:342 #18 0x00005555555d419b in do_modify (op=0x7ffee8002930, rs=0x7ffef49ff990) at ../../../head/servers/slapd/modify.c:211 #19 0x00005555555b1698 in connection_operation (ctx=0x7ffef49ffaf0, arg_v=0x7ffee8002930) at ../../../head/servers/slapd/connection.c:1126 #20 0x00005555555b1e06 in connection_read_thread (ctx=0x7ffef49ffaf0, argv=0xc) at ../../../head/servers/slapd/connection.c:1278 #21 0x00007ffff7f9fb45 in ldap_int_thread_pool_wrapper (xpool=0x55555586de80) at ../../../head/libraries/libldap/tpool.c:1059 #22 0x00007ffff7a94ac3 in ?? () from /lib/x86_64-linux-gnu/libc.so.6 #23 0x00007ffff7b26850 in ?? () from /lib/x86_64-linux-gnu/libc.so.6 (gdb)
There's an obvious problem with the groupOfUniqueNames objectclass, which requires that at least one uniqueMember value must always exist. That makes that class unsuitable for automated management with autogroup.
I'll look into this some more to see what went wrong in nestgroup.
https://bugs.openldap.org/show_bug.cgi?id=10320
--- Comment #6 from sergej@p5n.pp.ru --- I see some errors about failed deletion of all members by autogroup when ldap query result is empty but slapd does not crash on such operations, but may be it is the reason of further crashes.
Also it works very slow with autogroups, I rolled back my configuration to dyngroup
#overlay autogroup #autogroup-attrset labeledURIObject labeledURI uniqueMember #autogroup-memberof-ad memberOf
overlay dynlist dynlist-attrset labeledURIObject labeledURI uniqueMember
and it works fast enough and does not crash.
-
openldap-its＠openldap.org