[strongSwan-dev] Memory Corruption in plugin which connects to mysql db
mc
strongswan at sigterm.ch
Tue Mar 15 16:47:57 CET 2016
Hello list
Strongswan sometimes crashes in our setup, but only if we have several
users online and after some time. I could not reproduce it so far. It
looks like some memory corruption but I could not find the source yet..
We implemented a plugin for Strongswan, which uses the mysql plugin to
read/write to a mysql database..
When I run valgrind on strongswan, I get a lot of warnings like these:
==12943== Conditional jump or move depends on uninitialised value(s)
==12943== at 0xA289B51: my_net_read (in
/usr/lib64/mysql/libmysqlclient_r.so.16.0.0)
==12943== by 0xA284129: cli_safe_read (in
/usr/lib64/mysql/libmysqlclient_r.so.16.0.0)
==12943== by 0xA258FDE: cli_read_prepare_result (in
/usr/lib64/mysql/libmysqlclient_r.so.16.0.0)
==12943== by 0xA256212: mysql_stmt_prepare (in
/usr/lib64/mysql/libmysqlclient_r.so.16.0.0)
==12943== by 0xA02E5FF: run (mysql_database.c:293)
==12943== by 0xA02F59F: query (mysql_database.c:549)
==12943== by 0xE6B1DC6: get_pool (plumber_pool.c:116)
==12943== by 0xE6B2344: plumber_pool_create (plumber_pool.c:535)
==12943== by 0xE6AF950: open_database (plumber_plugin.c:123)
==12943== by 0x4E5ED45: load_provided (plugin_loader.c:721)
==12943== by 0x4E5F331: load_plugins (plugin_loader.c:804)
==12943== by 0x50A8122: initialize (daemon.c:827)
==12943== Uninitialised value was created by a stack allocation
==12943== at 0x8E58FB7: aesni_cbc_encrypt (in
/usr/lib64/libcrypto.so.1.0.1e)
==12943==
==12943== Use of uninitialised value of size 8
==12943== at 0xA289B57: my_net_read (in
/usr/lib64/mysql/libmysqlclient_r.so.16.0.0)
==12943== by 0xA284129: cli_safe_read (in
/usr/lib64/mysql/libmysqlclient_r.so.16.0.0)
==12943== by 0xA258FDE: cli_read_prepare_result (in
/usr/lib64/mysql/libmysqlclient_r.so.16.0.0)
==12943== by 0xA256212: mysql_stmt_prepare (in
/usr/lib64/mysql/libmysqlclient_r.so.16.0.0)
==12943== by 0xA02E5FF: run (mysql_database.c:293)
==12943== by 0xA02F59F: query (mysql_database.c:549)
==12943== by 0xE6B1DC6: get_pool (plumber_pool.c:116)
==12943== by 0xE6B2344: plumber_pool_create (plumber_pool.c:535)
==12943== by 0xE6AF950: open_database (plumber_plugin.c:123)
==12943== by 0x4E5ED45: load_provided (plugin_loader.c:721)
==12943== by 0x4E5F331: load_plugins (plugin_loader.c:804)
==12943== by 0x50A8122: initialize (daemon.c:827)
==12943== Uninitialised value was created by a stack allocation
==12943== at 0x8E58FB7: aesni_cbc_encrypt (in
/usr/lib64/libcrypto.so.1.0.1e)
The corresponding code is here:
plumber_pool.c:
static mem_pool_t *get_pool(private_plumber_pool_t *this, char *name,
int family)
{
enumerator_t *enumerator;
char *start_ip, *end_ip;
host_t *start_host, *end_host;
mem_pool_t *pool;
// try to find pool in the hashtable first, maybe it is allocated
already
this->mutex->lock(this->mutex);
pool = this->pools->get(this->pools, name);
if (pool) {
this->mutex->unlock(this->mutex);
return pool;
}
// Valgrind complains about this line. plumber_pool.c:116
enumerator = this->db->query(this->db,
"SELECT start, end FROM config_ippool WHERE name = ?",
DB_TEXT, name, DB_TEXT, DB_TEXT);
...
I checked that this->db is initialized, so is the variable name..
When I google for aesni_cbc_encrypt and valgrind, I find a lot of users
which complain about those messages. But most of the time it's just
recommended to ignore the warnings, as they're generated by the openssl
library..
Like here:
http://www.hardening-consulting.com/en/posts/20140512openssl-and-valgrind.html
But as I mentioned before, our server still crashes some times. Here is
a crashlog of the crashed thread from gdb:
Thread 12 (Thread 0x7f361327d700 (LWP 3405)):
#0 0x00007f362378909e in __lll_lock_wait_private () from
/lib64/libc.so.6
#1 0x00007f362370dc06 in _L_lock_44 () from /lib64/libc.so.6
#2 0x00007f362370684c in ptmalloc_lock_all () from /lib64/libc.so.6
#3 0x00007f362373db05 in fork () from /lib64/libc.so.6
#4 0x00007f36236f95f7 in _IO_proc_open@@GLIBC_2.2.5 () from
/lib64/libc.so.6
#5 0x00007f36236f98e9 in popen@@GLIBC_2.2.5 () from /lib64/libc.so.6
#6 0x00007f362459bfed in print_sourceline (file=0x0, filename=<value
optimized out>, ptr=<value optimized out>, base=<value optimized out>)
at utils/backtrace.c:401
#7 0x00007f362459c39d in log_ (this=0x7f35f8002100, file=0x0,
detailed=true) at utils/backtrace.c:468
#8 0x0000000000401298 in segv_handler (signal=11) at charon.c:186
#9 <signal handler called>
#10 0x00007f3623706fd5 in malloc_consolidate () from /lib64/libc.so.6
#11 0x00007f362370ac28 in _int_malloc () from /lib64/libc.so.6
#12 0x00007f362370bb1c in malloc () from /lib64/libc.so.6
#13 0x00007f361f45ebc2 in my_malloc () from
/usr/lib64/mysql/libmysqlclient_r.so.16
#14 0x00007f361f462435 in alloc_root () from
/usr/lib64/mysql/libmysqlclient_r.so.16
#15 0x00007f361f48765d in cli_read_rows () from
/usr/lib64/mysql/libmysqlclient_r.so.16
#16 0x00007f361f45c0c4 in cli_read_prepare_result () from
/usr/lib64/mysql/libmysqlclient_r.so.16
#17 0x00007f361f459213 in mysql_stmt_prepare () from
/usr/lib64/mysql/libmysqlclient_r.so.16
---Type <return> to continue, or q <return> to quit---
#18 0x00007f361f7bc600 in run (mysql=0x2242320,
sql=0x7f3616fbdf68 "UPDATE userauth_vpndevice SET kbytes_sent_month
= 0, kbytes_recv_month = 0 WHERE vpn_user_name = ? AND
(MONTH(FROM_UNIXTIME(last_seen)) != MONTH(CURDATE()) OR
YEAR(FROM_UNIXTIME(last_seen)) != YEAR(CU"...,
args=0x7f361327c1d0) at mysql_database.c:293
#19 0x00007f361f7bd481 in execute (this=0x22420a0, rowid=0x0,
sql=0x7f3616fbdf68 "UPDATE userauth_vpndevice SET kbytes_sent_month
= 0, kbytes_recv_month = 0 WHERE vpn_user_name = ? AND
(MONTH(FROM_UNIXTIME(last_seen)) != MONTH(CURDATE()) OR
YEAR(FROM_UNIXTIME(last_seen)) != YEAR(CU"...)
at mysql_database.c:640
#20 0x00007f3616fbaab3 in child_state_change (this=0x2292dd0,
ike_sa=<value optimized out>, child_sa=0x7f35e8008d70, state=<value
optimized out>) at plumber_stat.c:425
#21 0x00007f36242e153c in child_state_change (this=0x21f7950,
child_sa=0x7f35e8008d70, state=CHILD_INSTALLED) at bus/bus.c:523
#22 0x00007f36242fef4c in set_state (this=0x7f35e8008d70,
state=CHILD_INSTALLED) at sa/child_sa.c:262
#23 0x00007f36243167b8 in select_and_install (this=0x7f3604000e70,
no_dh=<value optimized out>, ike_auth=<value optimized out>) at
sa/ikev2/tasks/child_create.c:702
#24 0x00007f3624317801 in process_i (this=0x7f3604000e70,
message=0x7f35dc00c1b0) at sa/ikev2/tasks/child_create.c:1516
#25 0x00007f362431914d in process_i (this=0x7f35e800a6a0,
message=0x7f35dc00c1b0) at sa/ikev2/tasks/child_rekey.c:341
#26 0x00007f3624311b38 in process_response (this=0x7f361800a380,
msg=0x7f35dc00c1b0) at sa/ikev2/task_manager_v2.c:702
#27 process_message (this=0x7f361800a380, msg=0x7f35dc00c1b0) at
sa/ikev2/task_manager_v2.c:1473
#28 0x00007f3624301f07 in process_message (this=0x7f35d400bae0,
message=0x7f35dc00c1b0) at sa/ike_sa.c:1549
#29 0x00007f36242fcd47 in execute (this=0x7f35e8008710) at
processing/jobs/process_message_job.c:74
#30 0x00007f362458cde9 in process_job (worker=0x228f170) at
processing/processor.c:235
#31 process_jobs (worker=0x228f170) at processing/processor.c:321
#32 0x00007f362459e7ab in thread_main (this=0x228f1a0) at
threading/thread.c:322
#33 0x00007f3623c30aa1 in start_thread () from /lib64/libpthread.so.0
#34 0x00007f362377993d in clone () from /lib64/libc.so.6
Thanks for your help
mc
More information about the Dev
mailing list