这个BUG实际上早在4月份就被发现了，今年5月7号，MySQL发布5.5.24的时候，修正了这个BUG。

　　漏洞分析：

　　出问题的代码如下

　　my_bool check_scramble(const uchar *scramble_arg, const char *message,

　　const uint8 *hash_stage2)

　　{

　　SHA1_CONTEXT sha1_context;

　　uint8 buf[SHA1_HASH_SIZE];

　　uint8 hash_stage2_reassured[SHA1_HASH_SIZE];

　　mysql_sha1_reset(&sha1_context);

　　/* create key to encrypt scramble */ mysql_sha1_input(&sha1_context, (const uint8 *) message, SCRAMBLE_LENGTH);

　　mysql_sha1_input(&sha1_context, hash_stage2, SHA1_HASH_SIZE);

　　mysql_sha1_result(&sha1_context, buf);

　　/* encrypt scramble */ my_crypt((char *) buf, buf, scramble_arg, SCRAMBLE_LENGTH);

　　/* now buf supposedly contains hash_stage1: so we can get hash_stage2 */ mysql_sha1_reset(&sha1_context);

　　mysql_sha1_input(&sha1_context, buf, SHA1_HASH_SIZE);

　　mysql_sha1_result(&sha1_context, hash_stage2_reassured);

　　return memcmp(hash_stage2, hash_stage2_reassured, SHA1_HASH_SIZE);

　　}

　　memcmp的返回值实际上是int，而my_bool实际上是char。那么在把int转换成char的时候，就有可能发生截断。比如，memcmp返回0×200，截断后变成了0，调用check_scramble函数的就误以为“password is correct“。

　　但是一般来说，memcmp的返回值都在[127,-128]之内。glibc的经SSE优化后的代码，不是如此。所以这个BUG只在特定的编译环境下才会触发：即编译MySQL的时候加了-fno-builtin，并且所使用的glibc是经SSE优化后的(一般系统自带的都是如此)。这里所说的glibc是指Linux的glibc，FreeBSD的libc不受影响。

　　总的来说这个BUG还是比较严重的，上次MySQL出现这样的BUG还是在3.23/4.0时代。