==26183== ==26183== Invalid read of size 8 ==26183== at 0xFF0E29C: ldbm_usn_init (ldbm_usn.c:83) ==26183== by 0xFF20786: ldbm_back_start (start.c:300) ==26183== by 0x4CC34E3: plugin_call_func (plugin.c:1474) ==26183== by 0x4CC33D0: plugin_call_one (plugin.c:1442) ==26183== by 0x4CC2BE1: plugin_dependency_startall (plugin.c:1214) ==26183== by 0x4CC3302: plugin_startall (plugin.c:1404) ==26183== by 0x12F3CA: main (main.c:1187) ==26183== Address 0x80 is not stack'd, malloc'd or (recently) free'd ==26183== ==26183== ==26183== Process terminating with default action of signal 11 (SIGSEGV) ==26183== Access not within mapped region at address 0x80 ==26183== at 0xFF0E29C: ldbm_usn_init (ldbm_usn.c:83) ==26183== by 0xFF20786: ldbm_back_start (start.c:300) ==26183== by 0x4CC34E3: plugin_call_func (plugin.c:1474) ==26183== by 0x4CC33D0: plugin_call_one (plugin.c:1442) ==26183== by 0x4CC2BE1: plugin_dependency_startall (plugin.c:1214) ==26183== by 0x4CC3302: plugin_startall (plugin.c:1404) ==26183== by 0x12F3CA: main (main.c:1187) ==26183== If you believe this happened as a result of a stack ==26183== overflow in your program's main thread (unlikely but ==26183== possible), you can try to increase the size of the ==26183== main thread stack using the --main-stacksize= flag. ==26183== The main thread stack size used in this run was 8388608. ==26183==
62 void 63 ldbm_usn_init(struct ldbminfo li) ... 79 / Search each namingContext in turn */ 80 for ( sdn = slapi_get_first_suffix( &node, 0 ); sdn != NULL; 81 sdn = slapi_get_next_suffix_ext( &node, 0 )) { 82 be = slapi_mapping_tree_find_backend_for_sdn(sdn); 83 slapi_log_error(SLAPI_LOG_BACKLDBM, "ldbm_usn_init", 84 "backend: %s%s\n", be->be_name, isglobal?" (global mode)":""); <== crashed here; slapi_mapping_tree_find_backend_for_sdn returned 0x80?
git patch file (master) 0001-Ticket-47659-ldbm_usn_init-Valgrind-reports-Invalid-.patch
Bug description: A suffix mapping tree could exist without the corresponding backend. The existing code did not properly check the backend returned from slapi_mapping_tree_find_backend_for_sdn. When NULL backend is returned, it triggers the NULL pointer dereference.
Fix description: This patch added a NULL backend check to usn_get_last_usn, and moved a logging to the if clause where the backend is not NULL.
Reviewed by Rich (Thank you!!)
Pushed to master: 1e52401..a6f66e7 master -> master commit a6f66e7
Pushed to 389-ds-base-1.3.2: d598ed5..6ad2397 389-ds-base-1.3.2 -> 389-ds-base-1.3.2 commit 6ad2397
Pushed to 389-ds-base-1.3.1: 51714d8..412ec0e 389-ds-base-1.3.1 -> 389-ds-base-1.3.1 commit 412ec0e9c8367f2d1c446237cb2bc27791ea8e6c
Pushed to 389-ds-base-1.2.11: 8550aaf..4b7184c 389-ds-base-1.2.11 -> 389-ds-base-1.2.11 commit 4b7184c
Ticket has been cloned to Bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=1193243
Metadata Update from @nhosoi: - Issue assigned to nhosoi - Issue set to the milestone: 1.2.11.33
389-ds-base is moving from Pagure to Github. This means that new issues and pull requests will be accepted only in 389-ds-base's github repository.
This issue has been cloned to Github and is available here: - https://github.com/389ds/389-ds-base/issues/996
If you want to receive further updates on the issue, please navigate to the github issue and click on subscribe button.
subscribe
Thank you for understanding. We apologize for all inconvenience.
Metadata Update from @spichugi: - Issue close_status updated to: wontfix (was: Fixed)
Login to comment on this ticket.