openldap-bugs January 2021

openldap-bugs@openldap.org

1 participants
300 discussions

[Issue 7468] ppolicy and rwm/relay segfaulting
by openldap-its＠openldap.org 20 Jan '21

20 Jan '21

https://bugs.openldap.org/show_bug.cgi?id=7468 --- Comment #2 from Ondřej Kuzník <ondra(a)mistotebe.net> --- I have been able to reproduce this in master with the following config (no rwm involved): database relay suffix "ou=People,dc=example,dc=com" relay "dc=example,dc=com" database mdb suffix "dc=example,dc=com" rootdn "dc=example,dc=com" rootpw OBFUSCATED directory ./db3 overlay ppolicy ppolicy_default "cn=default,dc=example,dc=com" ppolicy_use_lockout ppolicy_hash_cleartext back-mdb hits a null pointer: 0x0000000000535161 in mdb_env_pick_meta (env=0x78f420) at ./../../../libraries/liblmdb/mdb.c:3944 3944 return metas[ metas[0]->mm_txnid < metas[1]->mm_txnid ]; (gdb) bt #0 0x0000000000535161 in mdb_env_pick_meta (env=0x78f420) at ./../../../libraries/liblmdb/mdb.c:3944 #1 0x000000000052feae in mdb_txn_renew0 (txn=0x7fffb6cef010) at ./../../../libraries/liblmdb/mdb.c:2688 #2 0x0000000000530914 in mdb_txn_begin (env=0x78f420, parent=0x0, flags=131072, ret=0x7fffe8004290) at ./../../../libraries/liblmdb/mdb.c:2910 #3 0x00000000005afe53 in mdb_opinfo_get (op=Bind request = {...}, mdb=0x78f1b0, rdonly=1, moip=0x7ffff61cad68) at id2entry.c:778 #4 0x00000000005af5d6 in mdb_entry_get (op=Bind request = {...}, ndn=0x7fffe8002bf8, oc=NULL, at=NULL, rw=0, ent=0x7ffff61cb388) at id2entry.c:607 #5 0x00000000004fd377 in overlay_entry_get_ov (op=Bind request = {...}, dn=0x7fffe8002bf8, oc=NULL, ad=NULL, rw=0, e=0x7ffff61cb388, on=0x0) at backover.c:378 #6 0x00000000004ffd36 in over_entry_get_rw (op=Bind request = {...}, dn=0x7fffe8002bf8, oc=NULL, ad=NULL, rw=0, e=0x7ffff61cb388) at backover.c:412 #7 0x0000000000466d6b in be_entry_get_rw (op=Bind request = {...}, ndn=0x7fffe8002bf8, oc=NULL, at=NULL, rw=0, e=0x7ffff61cb388) at backend.c:1443 #8 0x00007ffff791d0e3 in ppolicy_bind_response (op=Bind request = {...}, rs=0x7ffff61cb9f8) at ppolicy.c:1424 #9 0x000000000046d8d6 in slap_response_play (op=Bind request = {...}, rs=0x7ffff61cb9f8) at result.c:567 #10 0x000000000046948d in send_ldap_response (op=Bind request = {...}, rs=0x7ffff61cb9f8) at result.c:642 #11 0x000000000046a33e in slap_send_ldap_result (op=Bind request = {...}, rs=0x7ffff61cb9f8) at result.c:918 #12 0x000000000047f666 in fe_op_bind_success (op=Bind request = {...}, rs=0x7ffff61cb9f8) at bind.c:552 #13 0x000000000047f26c in fe_op_bind (op=Bind request = {...}, rs=0x7ffff61cb9f8) at bind.c:386 #14 0x000000000047e8ab in do_bind (op=Bind request = {...}, rs=0x7ffff61cb9f8) at bind.c:206 #15 0x00000000004528b7 in connection_operation (ctx=0x7ffff61cbb78, arg_v=0x7fffe8002bb0) at connection.c:1163 #16 0x0000000000450a90 in connection_read_thread (ctx=0x7ffff61cbb78, argv=0xc) at connection.c:1314 #17 0x00007ffff7fb01fe in ldap_int_thread_pool_wrapper (xpool=0x7266c0) at tpool.c:1051 (gdb) p metas[0] $1 = (MDB_meta * const) 0x0 -- You are receiving this mail because: You are on the CC list for the issue.

1 0

[Issue 7439] crash in rwm when tree is syncrepl synced and database ldap with rwm inside same tree
by openldap-its＠openldap.org 19 Jan '21

19 Jan '21

https://bugs.openldap.org/show_bug.cgi?id=7439 --- Comment #5 from Ondřej Kuzník <ondra(a)mistotebe.net> --- (In reply to Howard Chu from comment #4) > Right, rwm should probably stash the incoming filter and restore it on > return. The overlay seems quite confused in what it wants to do, parts of it want to maintain the original filter as is (rwm_callback_get, rwm_op_rollback) while parts are very intrusive (rwm_int_filter_map_rewrite). I'll see if I can change how rwm_int_filter_map_rewrite mangles the op/its filter. -- You are receiving this mail because: You are on the CC list for the issue.

1 0

[Issue 7439] crash in rwm when tree is syncrepl synced and database ldap with rwm inside same tree
by openldap-its＠openldap.org 19 Jan '21

19 Jan '21

https://bugs.openldap.org/show_bug.cgi?id=7439 --- Comment #4 from Howard Chu <hyc(a)openldap.org> --- (In reply to Ondřej Kuzník from comment #3) > Managed to repro with -DSLAP_NO_SL_MALLOC: > Don't know if rwm should stop freeing parts of provided filters or syncrepl > should allocate the avas. Probably the former... Right, rwm should probably stash the incoming filter and restore it on return. -- You are receiving this mail because: You are on the CC list for the issue.

1 0

[Issue 7439] crash in rwm when tree is syncrepl synced and database ldap with rwm inside same tree
by openldap-its＠openldap.org 19 Jan '21

19 Jan '21

https://bugs.openldap.org/show_bug.cgi?id=7439 --- Comment #3 from Ondřej Kuzník <ondra(a)mistotebe.net> --- Managed to repro with -DSLAP_NO_SL_MALLOC: ==317060== Thread 3: ==317060== Invalid free() / delete / delete[] / realloc() ==317060== at 0x48399AB: free (vg_replace_malloc.c:538) ==317060== by 0x48CAC24: ber_memfree_x (memory.c:152) ==317060== by 0x4E0CFC: slap_sl_free (sl_malloc.c:499) ==317060== by 0x4830D6: ava_free (ava.c:50) ==317060== by 0x459DB4: filter_free_x (filter.c:554) ==317060== by 0x52F9F92: rwm_int_filter_map_rewrite (rwmmap.c:772) ==317060== by 0x52F8AAF: rwm_filter_map_rewrite (rwmmap.c:824) ==317060== by 0x52EF17D: rwm_op_search (rwm.c:976) ==317060== by 0x508D20: overlay_op_walk (backover.c:691) ==317060== by 0x50BE40: over_op_func (backover.c:766) ==317060== by 0x50B031: over_op_search (backover.c:796) ==317060== by 0x5085B3: glue_sub_search (backglue.c:377) ==317060== by 0x505407: glue_op_search (backglue.c:534) ==317060== by 0x508D20: overlay_op_walk (backover.c:691) ==317060== by 0x50BE40: over_op_func (backover.c:766) ==317060== by 0x50B031: over_op_search (backover.c:796) ==317060== by 0x4FD3D9: syncrepl_entry (syncrepl.c:4007) ==317060== by 0x4F79C6: do_syncrep2 (syncrepl.c:1475) ==317060== by 0x4EF8D4: do_syncrepl (syncrepl.c:2067) ==317060== by 0x48A51FD: ldap_int_thread_pool_wrapper (tpool.c:1051) ==317060== Address 0x5bef807 is 7 bytes inside a block of size 24 alloc'd ==317060== at 0x483877F: malloc (vg_replace_malloc.c:307) ==317060== by 0x48CAD9C: ber_memalloc_x (memory.c:228) ==317060== by 0x48C4205: ber_get_stringbv (decode.c:519) ==317060== by 0x48C53FB: ber_scanf (decode.c:827) ==317060== by 0x4861B97: ldap_pvt_get_controls (controls.c:238) ==317060== by 0x4877E4F: ldap_get_entry_controls (getentry.c:106) ==317060== by 0x4F6A4A: do_syncrep2 (syncrepl.c:1284) ==317060== by 0x4EF8D4: do_syncrepl (syncrepl.c:2067) ==317060== by 0x48A51FD: ldap_int_thread_pool_wrapper (tpool.c:1051) ==317060== by 0x4CCEEA6: start_thread (pthread_create.c:477) ==317060== by 0x4DE5DEE: clone (clone.S:95) Don't know if rwm should stop freeing parts of provided filters or syncrepl should allocate the avas. Probably the former... -- You are receiving this mail because: You are on the CC list for the issue.

1 0

[Issue 9427] Integer underflow causes segfault in OpenLDAP: slapd v2.X - schema_init.c:issuerAndThisUpdateCheck:3932
by openldap-its＠openldap.org 18 Jan '21

18 Jan '21

https://bugs.openldap.org/show_bug.cgi?id=9427 Quanah Gibson-Mount <quanah(a)openldap.org> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |VERIFIED Group|OpenLDAP-devs | -- You are receiving this mail because: You are on the CC list for the issue.

1 0

[Issue 9425] A malicious unauthenticated packed crashes OpenLDAP in ad_keystring, ad.c:86
by openldap-its＠openldap.org 18 Jan '21

18 Jan '21

https://bugs.openldap.org/show_bug.cgi?id=9425 Quanah Gibson-Mount <quanah(a)openldap.org> changed: What |Removed |Added ---------------------------------------------------------------------------- Group|OpenLDAP-devs | Status|RESOLVED |VERIFIED -- You are receiving this mail because: You are on the CC list for the issue.

1 0

[Issue 9424] Integer undeflow causes segfault in OpenLDAP: slapd v2.X - schema_init.c:serialNumberAndIssuerCheck:4478
by openldap-its＠openldap.org 18 Jan '21

18 Jan '21

https://bugs.openldap.org/show_bug.cgi?id=9424 Quanah Gibson-Mount <quanah(a)openldap.org> changed: What |Removed |Added ---------------------------------------------------------------------------- Group|OpenLDAP-devs | Status|RESOLVED |VERIFIED -- You are receiving this mail because: You are on the CC list for the issue.

1 0

[Issue 9423] Assertion failure when decoding in ldap_X509dn2bv
by openldap-its＠openldap.org 18 Jan '21

18 Jan '21

https://bugs.openldap.org/show_bug.cgi?id=9423 Quanah Gibson-Mount <quanah(a)openldap.org> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |VERIFIED Group|OpenLDAP-devs | -- You are receiving this mail because: You are on the CC list for the issue.

1 0

[Issue 9420] New: memory leak & ub in servers/slapd/modrdn.c`slap_modrdn2mods()
by openldap-its＠openldap.org 18 Jan '21

18 Jan '21

https://bugs.openldap.org/show_bug.cgi?id=9420 Issue ID: 9420 Summary: memory leak & ub in servers/slapd/modrdn.c`slap_modrdn2mods() Product: OpenLDAP Version: unspecified Hardware: All OS: All Status: UNCONFIRMED Severity: normal Priority: --- Component: slapd Assignee: bugs(a)openldap.org Reporter: grapvar(a)gmail.com Target Milestone: --- Created attachment 781 --> https://bugs.openldap.org/attachment.cgi?id=781&action=edit fix Hi. I have noticed 1) a memory leak in failure cleanup section of slap_modrdn2mods(): | for ( ; op->orr_modlist != NULL; op->orr_modlist = tmp ) { | tmp = op->orr_modlist->sml_next; | ch_free( op->orr_modlist ); | } this code leaks (n)values of mods. And 2) undefined behavior while scheduling delete: | (void) (*desc->ad_type->sat_equality->smr_normalize)(..., &mod_tmp->sml_nvalues[0], ...) this code doesn't respect normalization failures, and may leave garbage in nvalues[0]. I guess this is because somebody assumed normalization can't fail here, because the value has already been normalized during dnPrettyNormal. But ... normalization can fail at least because some normalizators do not abort() on memory allocation failures. Here is a patch that fixes these defects. Please, consider. -- You are receiving this mail because: You are on the CC list for the issue.

1 4

[Issue 9417] New: ldapexop: exit with indeterminate status
by openldap-its＠openldap.org 18 Jan '21

18 Jan '21

https://bugs.openldap.org/show_bug.cgi?id=9417 Issue ID: 9417 Summary: ldapexop: exit with indeterminate status Product: OpenLDAP Version: unspecified Hardware: All OS: All Status: UNCONFIRMED Severity: normal Priority: --- Component: client tools Assignee: bugs(a)openldap.org Reporter: danix800(a)gmail.com Target Milestone: --- In clients/tools/ldapexop.c:354 'main' calls 'tool_exit' with testing result of 'code' to 'LDAP_SUCCESS' as argument, but clang static analyzer finds that at line 103 if 'ldap_whoami' fails then 'main' should exit, leaving 'code' uninitialized, the test result is indeterminate. After further inspection I can conclude that 'rc' is set all the way down so I think 'tool_exit' should be called with 'rc' directly. See MR!207 for potential fix for this. -- You are receiving this mail because: You are on the CC list for the issue.

1 3

← Newer
1
...
20
21
22
23
24
25
26
...
30
Older →

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs January 2021