#47659 ldbm_usn_init: Valgrind reports Invalid read / SIGSEGV
Closed: wontfix None Opened 7 years ago by nhosoi.

==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?


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

Metadata Update from @nhosoi:
- Issue assigned to nhosoi
- Issue set to the milestone: 1.2.11.33

4 years ago

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.

Thank you for understanding. We apologize for all inconvenience.

Metadata Update from @spichugi:
- Issue close_status updated to: wontfix (was: Fixed)

5 months ago

Login to comment on this ticket.

Metadata