Bug #99816 mysqldump crashes while handling invalid command options
Submitted: 9 Jun 2020 3:42 Modified: 10 Jun 2020 7:24
Reporter: Brian Yue (OCA) Email Updates:
Status: Closed Impact on me:
Category:MySQL Server: mysqldump Command-line Client Severity:S2 (Serious)
Version:MySQL8.0.18 OS:Any
Assigned to: CPU Architecture:Any

[9 Jun 2020 3:42] Brian Yue
For MySQL8.0.18 version, mysqldump will crash if command line options are like this:
mysqldump -uroot -p'123456' --default-character-set =utf8

[yxxdb_8018@localhost ~]$ mysqldump -uroot -p'123456' --default-character-set =utf8
terminate called after throwing an instance of 'std::out_of_range'
  what():  basic_string::substr: __pos (which is 2) > this->size() (which is 0)
Aborted (core dumped)

the reason for this is that invalid usage of string(didn't check length before use string)

How to repeat:
Just execute this: 
mysqldump -uroot -p'123456' --default-character-set =utf8
(there are spaces in a complete k-v param)

Suggested fix:
my method to fix this problem is checking length of string before using it, and insufficent length will lead to skipping analysis for current option string.

this code modification works for me:

--- a/mysys/my_default.cc
+++ b/mysys/my_default.cc
@@ -1378,6 +1378,7 @@ void update_variable_source(const char *opt_name, const char *value) {
   /* strip the value part if present */
   if (pos != string::npos) var_name = var_name.substr(0, pos);

+  if(var_name.length() < 2) return;
   /* remove -- */
   var_name = var_name.substr(2);
[9 Jun 2020 7:53] lalit Choudhary
Don't see the same behavior in MySQL 8.0.20

mysqldump -umsandbox -p'msandbox' --socket=/tmp/mysql_sandbox8020.sock --default-character-set =utf8 test
mysqldump: [Warning] Using a password on the command line interface can be insecure.
mysqldump: Character set '=utf8' is not a compiled character set and is not specified in the '/usr/local/mysql/share/charsets/Index.xml' file
[9 Jun 2020 9:23] MySQL Verification Team
Please check version 8.0.20. Thanks.
[10 Jun 2020 7:24] Brian Yue
thanks for you response!
  This problem cannot appear anymore in MySQL-8.0.20. 
  I have checked the code, this problem has been fixed in the latest version(8.0.20).