Full_Name: Leonid Yuriev Version: 2.4-HEAD OS: RHEL7 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (31.130.36.33) Monitor-backend shutdown code could call a callback from registered subsystem after it is already destroyed. For instance, currently ldap-backend frees its own registered context (lmi_mss from ldap_monitor_info_t) before than monitor_back_db_destroy() will be called. Therefore SIGSEGV would be occur on monitor shutdown if any ldap-backend database is configured and such freed context will be overwrited. This bug could be reproduced by a filling-memory-with-non-zero before calling free() from glibc.
back-monitor was designed before back-config, without considering the possibility of database removal during regular operations. There might be several flaws of that kind. My suggestion is that back-monitor is never shut down (it should be inhibited) except at slapd shutdown. Meanwhile, the code initialization and shutdown could be redesigned to properly handle those cases. On 25/02/2015 15:18, leo@yuriev.ru wrote: > Full_Name: Leonid Yuriev > Version: 2.4-HEAD > OS: RHEL7 > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (31.130.36.33) > > > Monitor-backend shutdown code could call a callback from registered subsystem > after it is already destroyed. > > For instance, currently ldap-backend frees its own registered context (lmi_mss > from ldap_monitor_info_t) before than monitor_back_db_destroy() will be called. > > Therefore SIGSEGV would be occur on monitor shutdown if any ldap-backend > database is configured and such freed context will be overwrited. > > This bug could be reproduced by a filling-memory-with-non-zero before calling > free() from glibc. > > > -- Pierangelo Masarati Associate Professor Dipartimento di Scienze e Tecnologie Aerospaziali Politecnico di Milano
pierangelo.masarati@polimi.it wrote: > back-monitor was designed before back-config, without considering the > possibility of database removal during regular operations. There might > be several flaws of that kind. Removal is not supported in 2.4. All of that is work-in-progress for 2.5. Patches welcome, but this is not a 2.4 bug. > My suggestion is that back-monitor is never shut down (it should be > inhibited) except at slapd shutdown. Meanwhile, the code initialization > and shutdown could be redesigned to properly handle those cases. > > On 25/02/2015 15:18, leo@yuriev.ru wrote: >> Full_Name: Leonid Yuriev >> Version: 2.4-HEAD >> OS: RHEL7 >> URL: ftp://ftp.openldap.org/incoming/ >> Submission from: (NULL) (31.130.36.33) >> >> >> Monitor-backend shutdown code could call a callback from registered subsystem >> after it is already destroyed. >> >> For instance, currently ldap-backend frees its own registered context (lmi_mss >> from ldap_monitor_info_t) before than monitor_back_db_destroy() will be called. >> >> Therefore SIGSEGV would be occur on monitor shutdown if any ldap-backend >> database is configured and such freed context will be overwrited. >> >> This bug could be reproduced by a filling-memory-with-non-zero before calling >> free() from glibc. >> >> >> > > -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/
Yes, Howard you are right. In our CI-process 'make test' crashes only for 2.5 branch. I was noted 2.4 in the ITS, it's my mistake. To fix this bug seems a de-registration should be provided by monitor-backend. 2015-02-25 17:47 GMT+03:00 Howard Chu <hyc@symas.com>: > pierangelo.masarati@polimi.it wrote: >> >> back-monitor was designed before back-config, without considering the >> possibility of database removal during regular operations. There might >> be several flaws of that kind. > > > Removal is not supported in 2.4. All of that is work-in-progress for 2.5. > Patches welcome, but this is not a 2.4 bug. > > >> My suggestion is that back-monitor is never shut down (it should be >> inhibited) except at slapd shutdown. Meanwhile, the code initialization >> and shutdown could be redesigned to properly handle those cases. >> >> On 25/02/2015 15:18, leo@yuriev.ru wrote: >>> >>> Full_Name: Leonid Yuriev >>> Version: 2.4-HEAD >>> OS: RHEL7 >>> URL: ftp://ftp.openldap.org/incoming/ >>> Submission from: (NULL) (31.130.36.33) >>> >>> >>> Monitor-backend shutdown code could call a callback from registered >>> subsystem >>> after it is already destroyed. >>> >>> For instance, currently ldap-backend frees its own registered context >>> (lmi_mss >>> from ldap_monitor_info_t) before than monitor_back_db_destroy() will be >>> called. >>> >>> Therefore SIGSEGV would be occur on monitor shutdown if any ldap-backend >>> database is configured and such freed context will be overwrited. >>> >>> This bug could be reproduced by a filling-memory-with-non-zero before >>> calling >>> free() from glibc. >>> >>> >>> >> >> > > > -- > -- Howard Chu > CTO, Symas Corp. http://www.symas.com > Director, Highland Sun http://highlandsun.com/hyc/ > Chief Architect, OpenLDAP http://www.openldap.org/project/
moved from Incoming to Development