openssl: [crash] mysql segfaults due to global_engine_lock being NULL
I use openssl-1.1.1g with mysql 5.7.30 client (mysql’s standard CLI application) and additional GOST engine for OpenSSL.
The command mysql segfaults at start when it calls SSL_load_error_strings() that is a wrapper for OPENSSL_init_ssl(). The problem does not manifest for non-threaded applications like openssl CLI application itself that works just fine with used external GOST engine. The problem does not occur if no external engines are configured within openssl.cnf. Also, the problem is specific for OpenSSL version 1.1.1 as it does not occur for OpenSSL 1.0.2 that has GOST engine built in.
The crash occurs in the engine_table_register() internal function of OpenSSL that calls CRYPTO_THREAD_write_lock(global_engine_lock) while it is still NULL (not initialized yet).
Here is the backtrace:
Reading symbols from /usr/local/bin/mysql...
[New LWP 100085]
Core was generated by `mysql'.
Program terminated with signal SIGSEGV, Segmentation fault.
#0 0x000000080202c136 in ?? () from /lib/libthr.so.3
(gdb) bt
#0 0x000000080202c136 in ?? () from /lib/libthr.so.3
#1 0x0000000803650dc8 in CRYPTO_THREAD_write_lock (lock=0x0)
at crypto/threads_pthread.c:78
#2 0x00000008035abcce in engine_table_register (
table=0x803951328 <cipher_table>,
cleanup=0x8035ad0a0 <engine_unregister_all_ciphers>, e=0x802e303c0,
nids=0x80325bd80 <gost_cipher_nids>, num_nids=12, setdefault=0)
at crypto/engine/eng_table.c:88
#3 0x00000008035ad05c in ENGINE_register_ciphers (e=0x802e303c0)
at crypto/engine/tb_cipher.c:30
#4 0x000000080300f760 in bind_gost (e=0x802e303c0, id=<optimized out>)
at /home/ports/security/gost-engine/work/engine-7ed64cd/gost_eng.c:269
#5 bind_engine (e=0x802e303c0, id=<optimized out>, fns=0x7fffffffdd98)
at /home/ports/security/gost-engine/work/engine-7ed64cd/gost_eng.c:312
#6 0x000000000069bcde in dynamic_load (e=0x802e303c0, ctx=0x802e1c420)
at crypto/engine/eng_dyn.c:480
#7 0x000000000069b6a2 in dynamic_ctrl (e=0x802e303c0, cmd=206, i=0, p=0x0,
f=0x0) at crypto/engine/eng_dyn.c:336
#8 0x00000000006fcf66 in ENGINE_ctrl (e=0x802e303c0, cmd=206, i=0, p=0x0,
f=0x0) at crypto/engine/eng_ctrl.c:174
#9 0x00000000006fd6b5 in ENGINE_ctrl_cmd_string (e=0x802e303c0,
cmd_name=0x705632 "LOAD", arg=0x0, cmd_optional=0)
at crypto/engine/eng_ctrl.c:289
#10 0x00000000006fc964 in int_engine_configure (name=0x802e201a0 "gost",
value=0x802e90600 "gost_section", cnf=0x802e7be00)
at crypto/engine/eng_cnf.c:90
#11 0x00000000006fc6a6 in int_engine_module_init (md=0x802e28210,
cnf=0x802e7be00) at crypto/engine/eng_cnf.c:171
#12 0x00000000004f2f6d in module_init (pmod=0x802e280f0,
name=0x802e20190 "engines", value=0x802e90520 "engine_section",
cnf=0x802e7be00) at crypto/conf/conf_mod.c:312
#13 0x00000000004f206f in module_run (cnf=0x802e7be00,
name=0x802e20190 "engines", value=0x802e90520 "engine_section", flags=50)
at crypto/conf/conf_mod.c:171
#14 0x00000000004f1ee7 in CONF_modules_load (cnf=0x802e7be00, appname=0x0,
flags=50) at crypto/conf/conf_mod.c:102
#15 0x00000000004f2230 in CONF_modules_load_file (filename=0x0, appname=0x0,
flags=50) at crypto/conf/conf_mod.c:138
#16 0x000000000064ec5f in openssl_config_int (settings=0x0)
at crypto/conf/conf_sap.c:69
#17 0x0000000000553ad4 in ossl_init_config () at crypto/init.c:293
#18 0x0000000000553669 in ossl_init_config_ossl_ () at crypto/init.c:291
#19 0x000000080202c5b8 in pthread_once () from /lib/libthr.so.3
#20 0x00000000005ad6ed in CRYPTO_THREAD_run_once (once=0xd2b0a8 <config>,
init=0x553660 <ossl_init_config_ossl_>) at crypto/threads_pthread.c:118
#21 0x00000000005530ca in OPENSSL_init_crypto (opts=2097230, settings=0x0)
at crypto/init.c:701
#22 0x0000000000498b5e in OPENSSL_init_ssl (opts=2097230, settings=0x0)
at ssl/ssl_init.c:205
#23 0x0000000000464e23 in ssl_start ()
at /home/ports/databases/mysql57-client/work/mysql-5.7.30/vio/viosslfactories.c:442
#24 0x00000000004373fc in mysql_server_init (argc=0,
argv=0xd22940 <embedded_server_args>,
groups=0xca0f00 <embedded_server_groups>)
at /home/ports/databases/mysql57-client/work/mysql-5.7.30/libmysql/libmysql.c:132
#25 0x0000000000413e1e in main (argc=2, argv=0x802e210e0)
at /home/ports/databases/mysql57-client/work/mysql-5.7.30/client/mysql.cc:1317
About this issue
- Original URL
- State: closed
- Created 4 years ago
- Comments: 15 (6 by maintainers)
Commits related to this issue
- databases/mysql57-client: fix SIGSEGV due to static OpenSSL linking As opposed to MySQL 8.0.x branch that switched to dynamic linking for OpenSSL libraries, MySQL 5.7.30 still statically links client... — committed to freebsd/freebsd-ports by deleted user 4 years ago
- databases/mysql57-client: fix SIGSEGV due to static OpenSSL linking As opposed to MySQL 8.0.x branch that switched to dynamic linking for OpenSSL libraries, MySQL 5.7.30 still statically links client... — committed to freebsd/freebsd-ports by joneum 4 years ago
- databases/mysql57-client: fix SIGSEGV due to static OpenSSL linking As opposed to MySQL 8.0.x branch that switched to dynamic linking for OpenSSL libraries, MySQL 5.7.30 still statically links client... — committed to Jehops/freebsd-ports-legacy by joneum 4 years ago
- MFH: r541739 databases/mysql57-client: fix SIGSEGV due to static OpenSSL linking As opposed to MySQL 8.0.x branch that switched to dynamic linking for OpenSSL libraries, MySQL 5.7.30 still staticall... — committed to freebsd/freebsd-ports by joneum 4 years ago
- MFH: r541739 databases/mysql57-client: fix SIGSEGV due to static OpenSSL linking As opposed to MySQL 8.0.x branch that switched to dynamic linking for OpenSSL libraries, MySQL 5.7.30 still staticall... — committed to freebsd/freebsd-ports by joneum 4 years ago
- databases/mysql57-client: fix SIGSEGV due to static OpenSSL linking As opposed to MySQL 8.0.x branch that switched to dynamic linking for OpenSSL libraries, MySQL 5.7.30 still statically links client... — committed to svmhdvn/freebsd-ports by joneum 4 years ago
I suspect right solution is to force MySQL link with OpenSSL dynamically instead of using static linking. AFAIK, this is already done for MySQL 8.0.x branch but 5.7.x still links it statically.
I’m testing it now.
That’s why I submitted the problem here and not for gost-engine.