CVE Request -- MySQL v5.1.49 -- multiple DoS flaws

[Jan Lieskovsky <jlieskov () redhat com>]

Hi Steve, vendors,

  MySQL upstream yet on 2010-07-09 released version v5.1.49 of their Community Server,
addressing couple of denial of service flaws (crashes and assertion failures):
[1] http://dev.mysql.com/doc/refman/5.1/en/news-5-1-49.html

1, Security Fix: After changing the values of the innodb_file_format or
                 innodb_file_per_table configuration parameters, DDL statements
                 could cause a server crash. (Bug#55039)
   References:   http://bugs.mysql.com/bug.php?id=55039
                 https://bugzilla.redhat.com/show_bug.cgi?id=628660
   Reason:       Assertion failure leading to server abort.

2, Security Fix: Joins involving a table with a unique SET column could cause
                 a server crash. (Bug#54575)
   References:   http://bugs.mysql.com/bug.php?id=54575
                 https://bugzilla.redhat.com/show_bug.cgi?id=628040
   Reason:       NULL pointer dereference leading to (temporary) server DoS.

3, Security Fix: Incorrect handling of NULL arguments could lead to a crash
                 for IN() or CASE operations when NULL arguments were either
                 passed explicitly as arguments (for IN()) or implicitly
                 generated by the WITH ROLLUP  modifier (for IN() and CASE).
                 (Bug#54477)
   References:   http://bugs.mysql.com/bug.php?id=54477
                 https://bugzilla.redhat.com/show_bug.cgi?id=628172
   Reason:       NULL pointer dereference leading to (temporary) server DoS.

4, Security Fix: A malformed argument to the BINLOG statement could result
                 in Valgrind warnings or a server crash. (Bug#54393)
   References:   http://bugs.mysql.com/bug.php?id=54393
                 https://bugzilla.redhat.com/show_bug.cgi?id=628062
   Reason:       Use of unassigned memory leading to (temporary) server DoS (crash).

5, Security Fix: Use of TEMPORARY  InnoDB tables with nullable columns could cause
                 a server crash. (Bug#54044)
   References:   http://bugs.mysql.com/bug.php?id=54044
                 https://bugzilla.redhat.com/show_bug.cgi?id=628192
   Reason:       Assertion failure leading to server abort.

6, Security Fix: The server could crash if there were alternate reads from
                 two indexes on a table using the HANDLER interface. (Bug#54007)
   References:   http://bugs.mysql.com/bug.php?id=54007
                 https://bugzilla.redhat.com/show_bug.cgi?id=628680
   Reason:       Assertion failure leading to server abort.

7, Security Fix: Using EXPLAIN with queries of the form SELECT ... UNION
                 ... ORDER BY (SELECT ... WHERE ...) could cause a server
                 crash. (Bug#52711)
   References:   http://bugs.mysql.com/bug.php?id=52711
                 https://bugzilla.redhat.com/show_bug.cgi?id=628328
   Reason:       NULL pointer dereference leading to (temporary) server DoS.

8, Security Fix: LOAD DATA INFILE did not check for SQL errors and sent an
                 OK packet even when errors were already reported. Also, an
                 assert related to client-server protocol checking in debug
                 servers sometimes was raised when it should not have been.
                 (Bug#52512)
   References:   http://bugs.mysql.com/bug.php?id=52512
                 https://bugzilla.redhat.com/show_bug.cgi?id=628698
   Reason:       Assertion failure leading to server abort.


It does not seem, CVE identifiers have been requested / assigned to these issues
yet (either went unnoticed or not serious enough the get separate CVE ids
[as it is possible on many distributions the majority of them would mean only
temporary denial of service]).

Steve, if 'went unnoticed' is the case, could you please assign CVE identifiers
for these?

Common references:
[2] http://secunia.com/advisories/41048/

Thanks && Regards, Jan.
--
Jan iankko Lieskovsky / Red Hat Security Response Team

P.S.: There is one crash due OOM killer issue yet:
      [3] http://bugs.mysql.com/bug.php?id=42064
      but that one is not something we would consider as being of a security issue.