https://bz.apache.org/bugzilla/show_bug.cgi?id=60947
Bug ID: 60947
Summary: Segfault on startup when using mod_ssl with APR-crypto
Product: Apache httpd-2
Version: 2.5-HEAD
Hardware: PC
OS: Linux
Status: NEW
Severity: normal
Priority: P2
Component: mod_ssl
Assignee: [email protected]
Reporter: [email protected]
Target Milestone: ---
mod_ssl's use of CRYPTO_THREADID_set_callback() is unfortunately bugged if
another module has loaded OpenSSL, either via the apr_crypto routines or some
other pathway.
When mod_ssl loads, it calls CRYPTO_THREADID_set_callback() as part of setting
up the thread-safety routines in OpenSSL. On unload, it attempts to unset this
callback by calling the registration function with a NULL argument. This always
fails, and the function returns zero, because unfortunately this API is
write-once.
*If* mod_ssl is the only OpenSSL consumer, then libcrypto will be unloaded and
reloaded and the OpenSSL static initialization will reset the callback, masking
any issue. But if something else has loaded OpenSSL as well (say, by using the
apr_crypto_* API), that threadid callback will now be pointing at junk.
Even after this, there's still a way to "succeed" -- *if* mod_ssl is reloaded
into exactly the same position, everything will proceed as normal. But if not,
we'll segfault the next time we call into OpenSSL. Currently, our Ubuntu
autotest machine is running into this crash.
Things we might consider:
- don't set any callback at all, and rely on OpenSSL's default threadid
callback
- for platforms on which the default threadid callback is unsafe/nonfunctional,
revert to the deprecated CRYPTO_set_id_callback(), which is not write-once
- talk to OpenSSL upstream to figure out the "right way" to deal with multiple
(possibly competing) OpenSSL consumers in the same address space
See also:
- bug 54357, which similarly discusses an inability to reset a static callback
in OpenSSL
- postgresql dev conversation on this:
https://postgrespro.com/list/id/[email protected]
--
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]
