This bug is for Oracle Critical Patch Update Advisory - April 2012 that lists 6 MySQL flaws: http://www.oracle.com/technetwork/topics/security/cpuapr2012-366314.html Fixes for these issues are included in versions 5.1.62 and 5.5.22. Previous CPU for MySQL was released in January 2012: http://www.oracle.com/technetwork/topics/security/cpujan2012-366304.html Security flaws in Jan 2012 CPU were fixed in versions 5.0.95, 5.1.61, and 5.5.20 (MySQL version 5.0.x reached end of life in between Jan and Apr CPUs). Therefore, following versions were released in between the two CPUs: http://dev.mysql.com/doc/refman/5.1/en/news-5-1-62.html http://dev.mysql.com/doc/refman/5.5/en/news-5-5-21.html http://dev.mysql.com/doc/refman/5.5/en/news-5-5-22.html The aim here is to try to document what fixes were made in those versions and try to map them to CVEs. This may not be possible to do with the information released via Oracle CPU (limited to CVSSv2 score and affected sub-component).
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