When looking for a terminating null character that isn't there and apparently

isn't supposed to be there as the length of the string is kept in a separate

variable. The code then tries to avoid a disaster by doing the right test after

it has done the wrong test, but with a bit of bad luck the out-of-bounds read

could cause a segmentation fault. Even if the error wouldn't affect the

operation of the code, fixing it will save programmers from wasting their time

chasing false alarms.

This patch reverses the order of the two tests. I suppose checking for null

characters is OK as an additional safety measure, but it needs to be done

conditionally after the length test to avoid an out-of-bounds read.

Upstream bug report: http://bugs.mysql.com/bug.php?id=64105

diff -up mysql-connector-odbc-5.2.5-src/util/stringutil.c.cond mysql-connector-odbc-5.2.5-src/util/stringutil.c

--- mysql-connector-odbc-5.2.5-src/util/stringutil.c.cond	2013-06-17 08:45:54.382640969 +0200

+++ mysql-connector-odbc-5.2.5-src/util/stringutil.c	2013-06-17 08:45:58.084640903 +0200

@@ -94,7 +94,7 @@ SQLWCHAR *sqlchar_as_sqlwchar(CHARSET_IN

     return NULL;

   }

-  for (pos= str, i= 0; *pos && pos < str_end; )

+  for (pos= str, i= 0; pos < str_end && *pos; )

   {

     if (sizeof(SQLWCHAR) == 4)

     {