MySQL Bugs: #57454: assertion in Format_description_log_event::calc_server_version

Bug #57454	assertion in Format_description_log_event::calc_server_version_split
Submitted:	14 Oct 2010 15:07	Modified:	13 Dec 2012 16:50
Reporter:	Shane Bester (Platinum Quality Contributor)	Email Updates:
Status:	Closed	Impact on me:	None
Category:	MySQL Server: Replication	Severity:	S2 (Serious)
Version:	5.5.6-debug, 5.6.99, 5.1 bzr	OS:	Any
Assigned to:	Luis Soares	CPU Architecture:	Any

Description:
101014 16:56:11 [Note] Slave I/O thread: connected to master 'root@192.168.1.100:3306',replication started in log 'xp64-bin.000001' at position 429
Assertion failed: !((i == 0) && (*r != '.')), file ..\..\mysql-5.5.6-rc\sql\log_event.cc, line 4203

mysqld-debug.exe!my_sigabrt_handler
mysqld-debug.exe!raise
mysqld-debug.exe!abort
mysqld-debug.exe!_wassert
mysqld-debug.exe!Format_description_log_event::calc_server_version_split
mysqld-debug.exe!Format_description_log_event::Format_description_log_event
mysqld-debug.exe!Log_event::read_log_event
mysqld-debug.exe!queue_event
mysqld-debug.exe!handle_slave_io
mysqld-debug.exe!pthread_start
mysqld-debug.exe!_callthreadstartex
mysqld-debug.exe!_threadstartex
kernel32.dll!BaseThreadStart

server_version pointed to a blank string ""

How to repeat:
repeated improper values given to master_log_pos in a change master command.:

stop slave;
change master to master_log_pos= .....;
start slave;

The problem is replication can be started at any master_log_pos and the master/slave will not do enough checking on the binlog position.  So, bogus errors like this are possible when you give a wrong position.

'log event entry exceeded max_allowed_packet;
'bogus data in log event'
'binlog truncated in the middle of event'
assertions, crashes.

I'd like proper boundary checking to be done on positions instead of just jumping into the middle of a binlog and reading garbage.  At least, we should fix crashes/valgrind errors.  More info later...

change master to master_host='127.0.0.1', master_port=3306, master_log_file='xp64-bin.000001',master_log_pos=192;start slave;

Attachment: xp64-bin.000001 (application/octet-stream, text), 135.88 KiB.

attached is a binlog and change master command to reproduce the issue...

Thank you for the report.

Verified as described.

This problem can also be triggered using a crafted (malformed) FORMAT DESCRIPTION EVENT sent in a base64 encoded BINLOG '....' statement.  Just set the server version to all NULL values to trigger the problem.

Crafting such an event leads to a DoS because the server will crash each time it receives such a malformed event.

This is mitigated somewhat by BINLOG requiring SUPER privs, but it is still an easily exploitable DoS.

Tested in 5.5.25

Thank you for your bug report. This issue has been committed to our source repository of that product and will be incorporated into the next release.

If necessary, you can access the source repository and build the latest available version, including the bug fix. More information about accessing the source trees is available at

    http://dev.mysql.com/doc/en/installing-source.html

Fixed in 5.1+, documented as follows in the MySQL 5.1.68, 5.5.30, 5.6.10, and 5.7.1 changelogs:

        Repeated execution of CHANGE MASTER TO statements using invalid
        MASTER_LOG_POS values could lead to errors and possibly a crash
        on the slave. Now in such cases, the statement fails with a
        clear error message.

Closed.