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.
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.
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.
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.
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.
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.
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.
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.
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.
https://bugs.openldap.org/show_bug.cgi?id=9414
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.