Commit 914cae3a authored by Mats Kindahl's avatar Mats Kindahl

Bug #37150 Risk for crash in User_var_log_event::exec_event()

On certain kinds of errors (e.g., out of stack), a call to Item_func_
set_user_var::fix_fields() might fail.  Since the return value of this
call was not checked inside User_var_log_event::exec_event(), continuing
execution after this will cause a crash inside Item_func_set_user_var::
update_hash().

The bug is fixed by aborting execution of the event with an error if
fix_fields() fails, since it is not possible to continue execution anyway.


sql/log_event.cc:
  Aborting execution of event if fix_fields() fails since execution
  of update_hash() might cause a crash.
parent fe87c0db
...@@ -4154,8 +4154,14 @@ int User_var_log_event::exec_event(struct st_relay_log_info* rli) ...@@ -4154,8 +4154,14 @@ int User_var_log_event::exec_event(struct st_relay_log_info* rli)
/* /*
Item_func_set_user_var can't substitute something else on its place => Item_func_set_user_var can't substitute something else on its place =>
0 can be passed as last argument (reference on item) 0 can be passed as last argument (reference on item)
Fix_fields() can fail, in which case a call of update_hash() might
crash the server, so if fix fields fails, we just return with an
error.
*/ */
e.fix_fields(thd, 0); if (e.fix_fields(thd, 0))
return 1;
/* /*
A variable can just be considered as a table with A variable can just be considered as a table with
a single record and with a single column. Thus, like a single record and with a single column. Thus, like
......
Markdown is supported
0%
or
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment