Bug#17081415:>=4GB ROW EVENT CRASHES SERVER WITH WILD MEMCPY
OF ROW DATA Problem: ======== Inserting a row larger than 4G when server uses RBR leads to crash. Analysis: ======== Row-based binary logging logs changes in individual table rows. During the execution of DML statements in RBR the actual row data will be stored within "m_rows_buf" buffer and this buffer contents will be written to binary log. "m_rows_buf" is prepared within the following function "Rows_log_event::do_add_row_data". When a huge row is specified as in this bug scenario where row size is 4294971520 > UINT_MAX (4294967295) then the "m_rows_buf" is reallocated to accommodate the row data and then the row is copied to the buffer. During this realloc call, the length is getting type casted to "uint" which results in overflow. Because of the overflow the reallocated memory happens to be incorrect than what was requested and it results in a crash during copy of rowdata to buffer. Hence rows of size > 4GB cannot be written to binary log. By default the event_length can be stored within 4 bytes which in turn restricts an event's size to grow. Hence large rows cannot be replicated using row based replication. Fix: === An error is generated if the row size exceeds 4GB value. sql/log_event.cc: An error is generated if the row size exceeds 4GB value. Debug simulations are added to test the fix.
Showing
Please register or sign in to comment