https://bz.apache.org/bugzilla/show_bug.cgi?id=60947
Paul Spangler <[email protected]> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |[email protected] --- Comment #2 from Paul Spangler <[email protected]> --- This comment isn't related to the particular issue you've described with the callback, but is related to the title of the bug. We've also seen a rare segfault when mixing mod_ssl with APR-crypto, but in SSL_load_error_strings (which is supposedly fixed in 1.1.0, see https://rt.openssl.org/Ticket/Display.html?user=guest&pass=guest&id=2325): 1. SSL_load_error_strings sets up a static hash table in libeay containing error strings, some of which point to memory in ssleay. 2. libapr loads apr_crypto_openssl, which bumps the refcount on libeay. 3. Server executes normally... until say the child process crashes or a graceful restart. 4. All modules are unloaded, but APR drivers are not (i.e. apr_crypto_openssl remains loaded). 5. During unload, ssleay gets unloaded but libeay remains loaded due to step 2. 6. Modules are loaded again. 7. ssleay may load into a different location than it was in step 1. 8. The hash table from step 1 still exists (in libeay), but now if it tries to check one of the SSL error strings, it points to a now-invalid place in memory, crashing. Our research led to this (somewhat old) mailing list thread: http://mailing.openssl.dev.narkive.com/syUDbGxq/memory-corruption-after-libssl-is-unloaded-from-memory where one of the devs is "not sure it has ever been a feasible goal to make OpenSSL DSO/DLLs able to be unloaded (with the aim of subsequently loading)." In the end, we decided it was safest to pin ssleay and libeay in memory for the lifetime of the server via a module that preloads them and never unloads them. That "solution" wouldn't fix this particular callback issue since it's related to mod_ssl moving in memory, but I figured this might be worth sharing anyway. Feel free to ignore if it's irrelevant :) Maybe the "fix" here would also be to pin whatever the callback points to in memory (if that would even be feasible) so it survives a mod_ssl reload? -- You are receiving this mail because: You are the assignee for the bug. --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
