MDEV-24901 SIGSEGV in fts_get_table_name, SIGSEGV in ib_vector_size, SIGSEGV in row_merge_fts_doc_tokenize, stack smashingbb-10.2-bar-MDEV-24901

strmake() puts one extra 0x00 byte at the end of the string.
The code in my_strnxfrm_tis620[_nopad] did not take this into
account, so in the reported scenario the 0x00 byte was put outside
of a stack variable, which made ASAN crash.

This problem is already fixed in in MySQL:

  commit 19bd66fe43c41f0bde5f36bc6b455a46693069fb
  Author: bin.x.su@oracle.com <>
  Date:   Fri Apr 4 11:35:27 2014 +0800

But the fix does not seem to be correct, as it breaks when finds a zero byte
in the source string.

Using memcpy() instead of strmake().

- Unlike strmake(), memcpy() it does not write beyond the destination
  size passed.
- Unlike the MySQL fix, memcpy() does not break on the first 0x00 byte found
  in the source string.

1 files changed, 29 insertions, 0 deletions

diff --git a/mysql-test/suite/innodb/t/innodb_ctype_tis620.test b/mysql-test/suite/innodb/t/innodb_ctype_tis620.test
new file mode 100644
index 00000000000..fee1b283ac3
--- /dev/null
+++ b/mysql-test/suite/innodb/t/innodb_ctype_tis620.test
@@ -0,0 +1,29 @@
+--source include/have_innodb.inc
+--source include/have_tis620.inc
+
+SET STORAGE_ENGINE=InnoDB;
+
+--echo #
+--echo # Start of 10.2 tests
+--echo #
+
+--echo #
+--echo #  MDEV-24901 SIGSEGV in fts_get_table_name, SIGSEGV in ib_vector_size, SIGSEGV in row_merge_fts_doc_tokenize, stack smashing Export
+--echo #
+
+CREATE TABLE t1(c TEXT CHARACTER SET tis620);
+SHOW CREATE TABLE t1;
+INSERT INTO t1 VALUES('100');
+ALTER TABLE t1 ADD FULLTEXT INDEX(c), ALGORITHM=INPLACE;
+DROP TABLE t1;
+
+CREATE TABLE t1(c TEXT CHARACTER SET tis620 COLLATE tis620_thai_nopad_ci);
+SHOW CREATE TABLE t1;
+INSERT INTO t1 VALUES('100');
+ALTER TABLE t1 ADD FULLTEXT INDEX(c), ALGORITHM=INPLACE;
+DROP TABLE t1;
+
+
+--echo #
+--echo # End of 10.2 tests
+--echo #