From 43d880b7e940f5c72f03a3d588b86162bda172e4 Mon Sep 17 00:00:00 2001 From: Praveenkumar Hulakund Date: Tue, 16 Sep 2014 11:28:46 +0530 Subject: Bug#19070633 - POSSIBLE ACCESS TO FREED MEMORY IN IS_FREE_LOCK() AND IS_USED_LOCK(). Analysis: ----------- In functions Item_func_is_free_lock::val_int() and Item_func_is_used_lock::val_int(), for the specified user lock name, pointer to its "User_level_lock" object is obtained from hash "hash_user_locks". Mutex "LOCK_user_locks" is acquired for this and released immediately. And we are accessing members of User_level_lock after releasing the mutex. If same user lock is deleted(released) from concurrent thread then accessing members results in invalid(freed) memory access issue. Deleting of user lock is also protected from the mutex "LOCK_user_locks". Since this mutex is released in "val_int" functions mentioned above, delete operation proceeds while concurrent thread tries to access its members. With the test case, valgrind reports invalid read issues in val_int functions. Fix: ----------- To fix this issue, in "val_int" function of classes "Item_func_is_free_lock" and "Item_func_is_used_lock", now releasing mutex "LOCK_user_locks" after accessing User_level_lock members. --- mysql-test/t/lock_sync.test | 55 +++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 55 insertions(+) (limited to 'mysql-test/t/lock_sync.test') diff --git a/mysql-test/t/lock_sync.test b/mysql-test/t/lock_sync.test index d5ad7becd7d..bcb78b5b600 100644 --- a/mysql-test/t/lock_sync.test +++ b/mysql-test/t/lock_sync.test @@ -1136,6 +1136,61 @@ DROP TABLE t1; disconnect con1; disconnect con2; +--echo # +--echo # Bug#19070633 - POSSIBLE ACCESS TO FREED MEMORY IN IS_FREE_LOCK() AND IS_USED_LOCK(). +--echo # + +--enable_connect_log + +--echo # Verifying issue for IS_FREE_LOCK() function. +SELECT GET_LOCK("lock_19070633", 600); + +connect (con1, localhost, root,,); +--echo # Waiting after getting user level lock info and releasing mutex. +SET DEBUG_SYNC= 'after_getting_user_level_lock_info SIGNAL parked WAIT_FOR go'; +--echo # Sending: SELECT IS_FREE_LOCK("lock_19070633"); +send SELECT IS_FREE_LOCK("lock_19070633"); + +connection default; +SET DEBUG_SYNC= 'now WAIT_FOR parked'; +SELECT RELEASE_LOCK("lock_19070633"); +--echo # Signaling connection con1 after releasing the lock. +--echo # Without fix, accessing user level lock info in con1 would result in +--echo # crash or valgrind issue invalid read is reported. +SET DEBUG_SYNC= 'now SIGNAL go'; + +connection con1; +--echo # Reaping: SELECT IS_FREE_LOCK("lock_19070633"); +--reap + +connection default; +--echo # Verifying issue for IS_USED_LOCK() function. +SELECT GET_LOCK("lock_19070633", 600); + +connection con1; +--echo # Waiting after getting user level lock info and releasing mutex. +SET DEBUG_SYNC= 'after_getting_user_level_lock_info SIGNAL parked WAIT_FOR go'; +--echo # Sending: SELECT IS_USED_LOCK("lock_19070633"); +send SELECT IS_USED_LOCK("lock_19070633"); + +connection default; +SET DEBUG_SYNC= 'now WAIT_FOR parked'; +SELECT RELEASE_LOCK("lock_19070633"); +--echo # Signaling connection con1 after releasing the lock. +--echo # Without fix, accessing user level lock info in con1 would result in +--echo # crash or valgrind issue invalid read is reported. +SET DEBUG_SYNC= 'now SIGNAL go'; + +connection con1; +--echo # Reaping: SELECT IS_USED_LOCK("lock_19070633"); +--replace_column 1 # +--reap + +connection default; +SET DEBUG_SYNC= 'RESET'; +disconnect con1; + +--disable_connect_log # Check that all connections opened by test cases in this file are really # gone so execution of other tests won't be affected by their presence. -- cgit v1.2.1