summaryrefslogtreecommitdiff
path: root/storage
diff options
context:
space:
mode:
authorPraveenkumar Hulakund <praveenkumar.hulakund@oracle.com>2014-09-16 11:28:46 +0530
committerPraveenkumar Hulakund <praveenkumar.hulakund@oracle.com>2014-09-16 11:28:46 +0530
commit43d880b7e940f5c72f03a3d588b86162bda172e4 (patch)
tree5c190174b0687f0eeb907c5304e5166c4c5315f6 /storage
parent4afd7e9ff21e5e2645dae6967fa9d83b4eed25a9 (diff)
downloadmariadb-git-43d880b7e940f5c72f03a3d588b86162bda172e4.tar.gz
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.
Diffstat (limited to 'storage')
0 files changed, 0 insertions, 0 deletions