| Bug #59248 | code review: write_row() crashes on INSERT...DUPLICATE KEY UPDATE | ||
|---|---|---|---|
| Submitted: | 31 Dec 2010 23:31 | Modified: | 22 Jan 2013 19:06 |
| Reporter: | Thomas Jones-Low | Email Updates: | |
| Status: | Closed | Impact on me: | |
| Category: | MySQL Server: DML | Severity: | S2 (Serious) |
| Version: | 5.5.8, 5.5.20 | OS: | Any |
| Assigned to: | CPU Architecture: | Any | |
[17 Dec 2011 19:07]
Valeriy Kravchuk
Based on code review it seems you are right.
[22 Jan 2013 19:06]
Paul DuBois
Bug discovered during code review. Does not manifest in released versions. No changelog entry needed.
Description: This bug was found by a code review and trying to debug our (incomplete) storage engine, not by any external SQL code and may not be able to be duplicated in any released storage engine. In the code handler::print_keydup_error (sql/handler.cc: line 2630) seems to imply that handler::get_dup_key() can return MAX_KEY for an unknown index. However in the function write_row(sql/sql_insert.cc: line 1542) there is: if ((int) (key_nr = table->file->get_dup_key(error)) < 0) key_copy((uchar*) key,table->record[0],table->key_info+key_nr,0); So if handler::get_dup_key() returns MAX_KEY while executing an INSERT ... ON DUPLICATE KEY UPDATE... the call to key_copy() generates a segfault and crashes the system. How to repeat: This was code review and does not have a working failure in the working system. Suggested fix: Validate the handler::get_dup_key() function should return only valid index ids.