Partitioning: When an ALTER TABLE ... REORGANIZE PARTITION statement on an InnoDB table failed due to innodb_lock_wait_timeout expiring while waiting for a lock, InnoDB did not clean up any temporary files or tables which it had created. Attempting to reissue the ALTER TABLE statement following the timeout could lead to storage engine errors, or possibly a crash of the server. (Bug#47343)

Referring to a subquery result in a HAVING clause could produce incorrect results. (Bug#50995)

The filesort sorting method applied to a CHAR(0) column could lead to a server crash. (Bug#49897)

sql_buffer_result had an effect on non-SELECT statements, contrary to the documentation. (Bug#49552)

In some cases a subquery need not be evaluated because it returns only aggregate values that can be calculated from table metadata. This sometimes was not handled by the enclosing subquery, resulting in a server crash. (Bug#49512)

If innodb_force_recovery was set to 4 or higher, the server could crash when opening an InnoDB table containing an auto-increment column. MySQL versions 5.1.31 and later were affected. (Bug#46193)

flush_cache_records() did not correctly check for errors that should cause statement execution to stop, leading to a server crash. (Bug#39022)