Bug #58003 | Segfault on CHECKSUM TABLE performance_schema.EVENTS_WAITS_HISTORY_LONG EXTENDED | ||
---|---|---|---|
Submitted: | 4 Nov 2010 23:32 | Modified: | 6 Jan 2011 1:05 |
Reporter: | Elena Stepanova | Email Updates: | |
Status: | Closed | Impact on me: | |
Category: | MySQL Server: Performance Schema | Severity: | S2 (Serious) |
Version: | 5.6.99-m5-debug | OS: | Any |
Assigned to: | Marc ALFF | CPU Architecture: | Any |
Tags: | checksum table |
[4 Nov 2010 23:32]
Elena Stepanova
[5 Nov 2010 6:12]
Marc ALFF
Analysis ======== Based on the new observations reported for this issue, the current situation seems to be: 1) The crash happened in: memcpy(m_row.m_object_name, wait->m_object_name, m_row.m_object_name_length); for WAIT_CLASS_TABLE 2) m_row.m_object_name_length is a valid length and within ranges, so the bug is not related to the object length, which passed the sanitize checks. 3) m_row.m_object_name is a valid region of memory, which could be printed under the debugger. The content of m_row.m_object_name shows multiple strings printed without a terminating 0, resulting in <...>.FRM<...>.FRM<...>.FRM for example for file names. This is actually expected, and per design, so there is nothing wrong here. 4) The crash was a signal 11 (segmentation violation). Given that the arguments given to memcpy are: - aligned on 1 byte (char*), this is not a byte alignment problem. Based on this, the remaining possible root cause is that the wait->m_object_name pointer itself is corrupted, and does not point to a valid region of memory. Considering that this crash has been consistently reported for TABLE EVENTS_WAITS_HISTORY_LONG, but never for TABLE EVENTS_WAITS_CURRENT, I suspect that the root cause is located in copy_events_waits(). The code uses a memcpy, which may copy different bytes of the 64 bits wait->m_object_name pointer at different times, leaving the pointer to an unsafe state. The solution is to sanitize the data even more, to make sure that wait->m_object_schema and wait->m_object_name are valid before de referencing these pointers.
[11 Nov 2010 11:36]
Bugs System
A patch for this bug has been committed. After review, it may be pushed to the relevant source trees for release in the next version. You can access the patch from: http://lists.mysql.com/commits/123590 3120 Marc Alff 2010-11-11 Bug#58003 Segfault on CHECKSUM TABLE performance_schema.EVENTS_WAITS_HISTORY_LONG EXTENDED This fix is a follow up on the fix for similar issue 56761. When sanitizing data read from the events_waits_history_long table, the code needs also to sanitize the schema_name / object_name / file_name pointers, because such pointers could also hold invalid values. Checking the string length alone was required but not sufficient. This fix verifies that: - the table schema and table name used in table io events - the file name used in file io events are valid pointers before dereferencing these pointers.
[15 Nov 2010 2:13]
Christopher Powers
Patch approved.
[16 Nov 2010 6:45]
Marc ALFF
Patch queued into: - mysql-5.5-bugteam - mysql-trunk-bugfixing
[5 Dec 2010 12:38]
Bugs System
Pushed into mysql-trunk 5.6.1 (revid:alexander.nozdrin@oracle.com-20101205122447-6x94l4fmslpbttxj) (version source revid:alexander.nozdrin@oracle.com-20101205122447-6x94l4fmslpbttxj) (merge vers: 5.6.1) (pib:23)
[11 Dec 2010 17:01]
Paul DuBois
But not present in any 5.6.x release. Setting report to Need Merge pending push into 5.5.x.
[16 Dec 2010 22:28]
Bugs System
Pushed into mysql-5.5 5.5.9 (revid:jonathan.perkin@oracle.com-20101216101358-fyzr1epq95a3yett) (version source revid:jonathan.perkin@oracle.com-20101216101358-fyzr1epq95a3yett) (merge vers: 5.5.9) (pib:24)
[4 Jan 2011 8:17]
Marc ALFF
Fix present in mysql-5.5.9, in branch mysql-5.5
[6 Jan 2011 1:05]
Paul DuBois
Noted in 5.5.8 changelog. The server could crash inside memcpy() when reading certain Performance Schema tables.