Thursday, October 19, 2017

A crashing bug in MySQL: the CREATE TABLE of death (more fun with InnoDB Persistent Statistics)

I ended one of my last posts - Fun with InnoDB Persistent Statistics - with a cryptic sentence: there is more to say about this but I will stop here for now.  What I did not share at the time is the existence of a crashing bug somehow related to what I found.  But let's start with some context.

In Bug#86926, I found a way to put more than 64 characters in the field table_name of the mysql.innodb_table_stats table (which is a varchar(64)).  This field uses the utf8 (utf8mb3) character set, so the internal representation of the data is using a length field of a single byte (64*3 = 192 which is smaller than 256).  I wondered if I could have MySQL put a string longer than 255 bytes in that field, so I crafted a CREATE TABLE to try it, and that CREATE TABLE crashed all of below versions (it probably crashes many other versions, I only checked those):
  • MySQL 5.6.35, 5.7.17, 5.7.18 and 8.0.1,
  • MariaDB 10.0.29, 10.1.23 and 10.2.6,
  • Percona Server 5.6.36 and 5.7.18.
The scary thing is that one only needs CREATE TABLE privileges for crashing the database !

Note: this crash is not related to InnoDB Persistent Statistics (I will probably share the details in a later post).  However, as this bug was found when I was stressing the implementation of InnoDB Persistent Statistics, the title more fun with InnoDB Persistent Statistics is still relevant.

I did not immediately talk about this because this kind of information is dangerous in the wrong hands, because I wanted to give the vendors a chance to fix the issue, and because I also wanted to give users a chance to upgrade.  I (hopefully) responsibly reported this as a security bug to Oracle on July 4th (Bug#86934 which is private) and also sent the information to the MariaDB Corporation, to the MariaDB Foundation, and to Percona.  In those reports, I wrote that I would share this information in three months or one month after a fix has been published.  Both delays are expired.

Here is the progress on fixing this bug (I might update below after the post has been published):
  • I reported the bug on July 4th,
  • MariaDB 10.2.7 was released with a fix on July 12th,
  • MariaDB 5.5.57 was released with a fix on July 19th,
  • MariaDB 10.0.32 was released with a fix on August 7th,
  • MariaDB 10.1.26 was released with a fix on August 10th,
  • MySQL 5.5.58, 5.6.38 and 5.7.20 were released with a fix on October 16th (Bug #26390632 in the release notes),
  • ...

I am not yet publishing the CREATE TABLE of death as I want to let people upgrade.  I might do it in the future.

And last, so people searching Google can get to this post, below is the crash report in the MySQL 5.7.17 error log when running a CREATE TABLE of death:
InnoDB: Failing assertion: norm_len < FN_REFLEN - 1
InnoDB: We intentionally generate a memory trap.
InnoDB: Submit a detailed bug report to
InnoDB: If you get repeated assertion failures or crashes, even
InnoDB: immediately after the mysqld startup, there may be
InnoDB: corruption in the InnoDB tablespace. Please refer to
InnoDB: about forcing recovery.
14:45:53 UTC - mysqld got signal 6 ;
This could be because you hit a bug. It is also possible that this binary
or one of the libraries it was linked against is corrupt, improperly built,
or misconfigured. This error can also be caused by malfunctioning hardware.
Attempting to collect some information that could help diagnose the problem.
As this is a crash and something is definitely wrong, the information
collection process might fail.

It is possible that mysqld could use up to
key_buffer_size + (read_buffer_size + sort_buffer_size)*max_threads = 4282463 K  bytes of memory
Hope that's ok; if not, decrease some variables in the equation.

Thread pointer: 0x7f9dc42ddbd0
Attempting backtrace. You can use the following information to find out
where mysqld died. If you see no messages after this, something went
terribly wrong...
stack_bottom = 7f9e7507be70 thread_stack 0x40000

Trying to get some variables.
Some pointers may be invalid and cause the dump to abort.
Query (7f9dc430c4a0): CREATE TABLE test_jfg.[...]
Connection ID (thread ID): 5958


  1. I am holding (not publishing yet) a comment that gives too much information about the CREATE Table of Death. I will publish it later.

    1. Thank you for not publishing the syntax/how to. It is an interesting point,many do not police or limit table creations. The micro services generation are enhanced by this ability to create on demand. This could take many production systems down.

    2. You are right that restricting the right for table creation is a way to mitigate this problem.

      However, to be perfectly clear, I intend to eventually (in 4 to 12 weeks) publish a full explanation of the CREATE TABLE of death, including how to crash a vulnerable MySQL/MariaDB. I believe that this type of information should not be kept private for too long, especially that some people already know the CREATE TABLE of death and many people are able to figure-out enough about is with the information that is already out there.