From 2f33b5a49d3776a344e9b44ef372fc3457143a11 Mon Sep 17 00:00:00 2001 From: Daiki Ueno Date: Wed, 21 Sep 2016 15:06:41 +0200 Subject: [PATCH 1/3] rpc: Fix memleak in rpc_socket cleanup GCC's asan spotted this: Direct leak of 120 byte(s) in 1 object(s) allocated from: #0 0x7f8d4f221fe0 in calloc (/lib64/libasan.so.3+0xc6fe0) #1 0x427f55 in rpc_socket_new ../p11-kit/rpc-transport.c:100 #2 0x42bc1b in rpc_exec_connect ../p11-kit/rpc-transport.c:767 --- p11-kit/rpc-transport.c | 1 + 1 file changed, 1 insertion(+) diff --git a/p11-kit/rpc-transport.c b/p11-kit/rpc-transport.c index 5251e1169..13d13727a 100644 --- a/p11-kit/rpc-transport.c +++ b/p11-kit/rpc-transport.c @@ -163,6 +163,7 @@ rpc_socket_unref (rpc_socket *sock) rpc_socket_close (sock); p11_mutex_uninit (&sock->write_lock); p11_mutex_uninit (&sock->read_lock); + free (sock); } static bool From b3aff0d3b27984a5f605a691a6bb19809ee0cd37 Mon Sep 17 00:00:00 2001 From: Daiki Ueno Date: Wed, 21 Sep 2016 15:30:55 +0200 Subject: [PATCH 2/3] modules: Fix memleak when loading remote module Make sure to call p11_virtual_uninit() on managed module. Otherwise the associated lower_module will not be released. GCC's asan spotted this: Direct leak of 56 byte(s) in 1 object(s) allocated from: #0 0x7f6c5368dfe0 in calloc (/lib64/libasan.so.3+0xc6fe0) #1 0x4436ba in p11_rpc_client_init ../p11-kit/rpc-client.c:2082 #2 0x42c147 in p11_rpc_transport_new ../p11-kit/rpc-transport.c:850 #3 0x415d95 in setup_module_for_remote_inlock ../p11-kit/modules.c:411 --- p11-kit/modules.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/p11-kit/modules.c b/p11-kit/modules.c index 6e15c1d18..4af2a83d6 100644 --- a/p11-kit/modules.c +++ b/p11-kit/modules.c @@ -251,6 +251,8 @@ free_module_unlocked (void *data) assert (mod->initialize_thread == 0); } + p11_virtual_uninit (&mod->virt); + if (mod->loaded_destroy) mod->loaded_destroy (mod->loaded_module); From b9b45adf7798983f99084f6f3f700ffd4a3e05c1 Mon Sep 17 00:00:00 2001 From: Daiki Ueno Date: Thu, 22 Sep 2016 09:16:48 +0200 Subject: [PATCH 3/3] modules: Reset the init count on fork() Reset mod->init_count when forkid has changed. Otherwise C_Finalize does not get called. GCC's asan spotted this: Direct leak of 48 byte(s) in 1 object(s) allocated from: #0 0x7f89bc7bfe20 in malloc (/lib64/libasan.so.3+0xc6e20) #1 0x7f89bc47a1f1 in p11_dict_new ../common/dict.c:278 #2 0x7f89bc42143d in managed_C_Initialize ../p11-kit/modules.c:1477 #3 0x7f89bc464c72 in binding_C_Initialize ../p11-kit/virtual.c:121 #4 0x7f89bc1b0a51 in ffi_closure_unix64_inner (/lib64/libffi.so.6+0x5a51) #5 0x7f89bc1b0dbf in ffi_closure_unix64 (/lib64/libffi.so.6+0x5dbf) #6 0x7f89bc44f9e8 in rpc_C_Initialize ../p11-kit/rpc-server.c:691 --- p11-kit/modules.c | 4 ++++ 1 file changed, 4 insertions(+) diff --git a/p11-kit/modules.c b/p11-kit/modules.c index 4af2a83d6..fc456ce7b 100644 --- a/p11-kit/modules.c +++ b/p11-kit/modules.c @@ -658,6 +658,10 @@ initialize_module_inlock_reentrant (Module *mod, CK_C_INITIALIZE_ARGS *init_args /* Module was already initialized, we don't call C_Finalize */ if (rv == CKR_CRYPTOKI_ALREADY_INITIALIZED) rv = CKR_OK; + + /* Matches the init count in finalize_module_inlock_reentrant() */ + if (rv == CKR_OK) + mod->init_count = 0; } p11_mutex_unlock (&mod->initialize_mutex);