You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
MDEV-34322: ASAN heap-buffer-overflow in Field::is_null / Item_param::assign_default or bogus ER_BAD_NULL_ERROR
Execution of UPDATE statement on a table that has an associated trigger
and the UPDATE statement tries to modify a column having the DEFAULT
clause, could result in either assert firing or incorrect issuing of
the ER_BAD_NULL_ERROR error.
The reason of such behaviour is that on opening of a table that has
an associated trigger, the method
Table_triggers_list::prepare_record_accessors
called to prepare Field objects referencing TABLE::record[1] instead
of record[0]. This method allocates a new array of Field objects
as copies of original table fields but updated null_ptr data
members pointing to an array of extra_null_bitmap allocated before
that on table's mem_root. Later switch_to_nullable_trigger_fields()
is called where table' fields is switched to the new array allocated at
Table_triggers_list::prepare_record_accessors().
After that, when fill_record() is invoked to fill table fields with
values, so the make_default_field is invoked to handle the clause
DEFAULT and the function make_default_field() called to create a field
object. The function make_default_field() creates a copy of Field
object and updates its data member prt/null_tr to position their to
right place of table's record buffer, but since the method
Table_triggers_list::prepare_record_accessors
has been invoked before, the expression
def_field->table->s->default_values - def_field->table->record[0]
used for pointers adjustment leads to pointing to arbitrary memory not
associated with the table.
To fix the issue, use the TABLE_SHARE fields for referencing to columns
default values.
0 commit comments