summaryrefslogtreecommitdiff
path: root/sql/table.cc
diff options
context:
space:
mode:
authorAlexander Barkov <bar@mariadb.com>2021-10-13 12:57:57 +0400
committerAlexander Barkov <bar@mariadb.com>2021-10-14 10:16:23 +0400
commita2a42f4eba7409264d4b4fb2dc7c04e40c50bd25 (patch)
tree86e8de3020f8534b0efac9b369bcfa4dcf0b83cb /sql/table.cc
parentbbae2d398f866b00f7e8ad71984884ff3375df52 (diff)
downloadmariadb-git-a2a42f4eba7409264d4b4fb2dc7c04e40c50bd25.tar.gz
MDEV-23408 Wrong result upon query from I_S and further Assertion `!alias_arg || strlen(alias_arg->str) == alias_arg->length' failed with certain connection charset
There were two independent problems which lead to the crash and to the non-relevant records returned in I_S queries: - The code in the I_S implementation was not secure about values with 0x00 bytes. It's fixed by using check_db_name() and check_table_name() inside make_table_name_list(), and by adding the test for 0x00 inside check_table_name(). - The code in Item_string::print() did not convert strings without introducers when restoring the CREATE VIEW statement from an Item tree. This made wrong literals inside the "query" line in the view FRM file in cases when the VIEW parse time character_set_client!=character_set_connection. That's fixed by adding a proper conversion. This change also fixed a similar problem in SHOW PROCEDURE CODE - the literals were displayed in wrong character set in SP instructions in cases when the SP parse time character_set_client!=character_set_connection.
Diffstat (limited to 'sql/table.cc')
-rw-r--r--sql/table.cc15
1 files changed, 15 insertions, 0 deletions
diff --git a/sql/table.cc b/sql/table.cc
index 87b3c158a67..d4f8170e0af 100644
--- a/sql/table.cc
+++ b/sql/table.cc
@@ -4183,6 +4183,21 @@ bool check_table_name(const char *name, size_t length, bool check_for_path_chars
if (check_for_path_chars &&
(*name == '/' || *name == '\\' || *name == '~' || *name == FN_EXTCHAR))
return 1;
+ /*
+ We don't allow zero byte in table/schema names:
+ - Some code still uses NULL-terminated strings.
+ Zero bytes will confuse this code.
+ - There is a little practical use of zero bytes in names anyway.
+ Note, if the string passed as "name" comes here
+ from the parser as an identifier, it does not contain zero bytes,
+ as the parser rejects zero bytes in identifiers.
+ But "name" can also come here from queries like this:
+ SELECT * FROM I_S.TABLES WHERE TABLE_NAME='str';
+ In this case "name" is a general string expression
+ and it can have any arbitrary bytes, including zero bytes.
+ */
+ if (*name == 0x00)
+ return 1;
name++;
name_length++;
}