diff options
author | Praveenkumar Hulakund <praveenkumar.hulakund@oracle.com> | 2014-09-16 11:28:46 +0530 |
---|---|---|
committer | Praveenkumar Hulakund <praveenkumar.hulakund@oracle.com> | 2014-09-16 11:28:46 +0530 |
commit | 43d880b7e940f5c72f03a3d588b86162bda172e4 (patch) | |
tree | 5c190174b0687f0eeb907c5304e5166c4c5315f6 /storage | |
parent | 4afd7e9ff21e5e2645dae6967fa9d83b4eed25a9 (diff) | |
download | mariadb-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