Bug 832477 (mysql-cpu-2012-04)

The only security fix that is mentioned in the released notes is:

 * Security Fix: Bug #63775 was fixed.

mentioned in the 5.1.62 and 5.5.22 release notes.  The commit summary is:

Fix Bug#13510739 63775: SERVER CRASH ON HANDLER READ NEXT AFTER DELETE RECORD

This got CVE-2012-2102 assigned publicly few days before CPU release:

http://thread.gmane.org/gmane.comp.security.oss.general/7430

The CVE is not mentioned in the Apr 2012 CPU.  It is possible that one of the CVE-2012-1703, CVE-2012-1688 or CVE-2012-1690 is a duplicate assignment, however there's not much info to be sure.  CVE-2012-1703 is CVSS scored as having complete availability impact and described as:

  Successful attack of this vulnerability can result in unauthorized
  Operating System hang or frequently repeatable crash (complete DOS).

http://www.oracle.com/technetwork/topics/security/cpuapr2012verbose-366316.html#Oracle%20MySQL

As it is mysqld crash, it's more likely to be one of the other two CVEs that are scored as having partial+ availability impact:

  Successful attack of this vulnerability can result in unauthorized ability
  to cause a hang or frequently repeatable crash (complete DOS) of MySQL
  Server.

Neither of the two CVEs is listed as affecting InnoDB sub-component, while other storage engine - MyISAM - is listed as sub-component for CVE-2012-0583.

This issue is tracked via bug #812431.

CVE-2012-0583 is rather odd, as it is listed to affect versions before 5.1.61 and 5.5.20.  Given those versions, it seems it should have been listed in the Jan 2012 CPU.  A possibility is that the issue also affected 5.0 versions, but did not get fixed in 5.0.95.

One candidate is:
http://bazaar.launchpad.net/~mysql/mysql-server/5.1/revision/1810.4002.1
Bug#12361113: CRASH WHEN "LOAD INDEX INTO CACHE" WITH TOO
SMALL KEY CACHE

This fix addressed mysqld crasher bug and was applied in versions 5.1.61 and 5.5.20.  Additionally, it got applied to 5.0 in 5.0.96.  5.0.96 release notes do not mention any security fix though:
http://dev.mysql.com/doc/refman/5.0/en/news-5-0-96.html

Additional notes regarding the test case that is part of the linked commit:

- 5.1 versions before 5.1.61 can be crashed using it, but it does not seem to crash 5.0.95 as shipped with Red Hat Enterprise Linux 5.

- Test case requires SUPER privilege, so can only be executed using MySQL root user or other user with database admin privileges.  The privilege is required for the "SET GLOBAL" use.  Unclear if there may be other way not requiring admin privileges to trigger this issue.

A likely candidate for CVE-2012-1703 is the following commit:

http://bazaar.launchpad.net/~mysql/mysql-server/5.1/revision/3560.9.1
Bug #11765810 58813: SERVER THREAD HANGS WHEN JOIN + WHERE + GROUP BY
IS EXECUTED TWICE FROM P

This allows non-admin user with SQL access to make mysqld enter an infinite loop, consuming lot of CPU time.  This would also match A:C part of the CVSS score.

The issue also affects MySQL 5.0 and was not fixed in 5.0.96.

Another suspicious commit among the changes done in between 5.1.61 and 5.1.62, that is a possible candidate for CVE-2012-1690 is:

http://bazaar.launchpad.net/~mysql/mysql-server/5.1/revision/3560.8.5
Bug#12663165 SP DEAD CODE REMOVAL DOESN'T UNDERSTAND CONTINUE HANDLERS

According to the commit message, it could "lead to assertions, crashes and generally bad behavior".  The test case does not seem to trigger any of that behavior on mysql 5.0.95 and 5.1.61 packages in Red Hat Enterprise Linux.

One observation is that debug build assertion failures do not seem to be considered security.  For example following commit documents a possibility of triggering DBUG_ASSERT, but is documented in 5.1.62 and 5.5.21 as "Incompatible Change".

http://bazaar.launchpad.net/~mysql/mysql-server/5.1/revision/3671