Details
-
Bug
-
Status: Closed (View Workflow)
-
Blocker
-
Resolution: Fixed
-
10.5.9, 10.2(EOL), 10.3(EOL), 10.4(EOL), 10.5, 10.6, 10.7(EOL)
-
Ubuntu 18.04
MariaDB 10.5.9
Description
I used my fuzzing tool to test Mariadb , and found a bug that can result in an heap-use-after-free (reported by ASAN).
Mariadb installation：
1) cd mariadb-10.5.9
2) mkdir build; cd build
3) cmake -DWITH_ASAN=ON -DWITH_ASAN_SCOPE=ON -DWITH_DEBUG=ON ../
4) make -j8 && sudo make install
How to Repeat:
export ASAN_OPTIONS=detect_leaks=0
/usr/local/mysql/bin/mysqld_safe &
/usr/local/mysql/bin/mysql -uroot -p123456(your password)
MariaDB> drop database if exists test_db;
MariaDB> create database test_db;
MariaDB> source fuzz.sql;
I have simplified the content of fuzz.sql, and I hope fuzz.sql can help you reproduce the bug and fix it. In addition, I attach the ASAN report.
Attachments
Issue Links
- blocks
-
-
- Closed
-
- is duplicated by
-
-
- Closed
-
-
-
- Closed
-
-
-
- Closed
-
-
-
- Closed
-
- relates to
-
-
- Confirmed
-
-
-
- Confirmed
-
-
-
- Closed
-
- links to
Activity
The problem is that convert_const_to_int() trys to store value of the field x (because there is no flag STATUS_NO_RECORD), but the record in the process of the opening the field looks like contain a garbage.
So flag STATUS_NO_RECORD should be put if thee is no record in the buffer yet (and it shoud not be value in the buffer because it is creation of the field)
There is 3 problems
1) Above (absence of STATUS_NO_RECORD)
diff --git a/sql/table.cc b/sql/table.cc
|
index ca6ce02e4f2..ccd08a692d4 100644
|
--- a/sql/table.cc
|
+++ b/sql/table.cc
|
@@ -3088,6 +3088,7 @@ enum open_frm_error open_table_from_share(THD *thd, TABLE_SHARE *share,
|
outparam->s= share;
|
outparam->db_stat= db_stat;
|
outparam->write_row_record= NULL;
|
+ outparam->status= STATUS_NO_RECORD;
|
|
if (share->incompatible_version &&
|
!(ha_open_flags & (HA_OPEN_FOR_ALTER | HA_OPEN_FOR_REPAIR)))
|
2) mismatch signed unsigned (I belive can be made separate test with big numbers:
diff --git a/sql/item_cmpfunc.cc b/sql/item_cmpfunc.cc
|
index 3a76982d80e..0907ec64232 100644
|
--- a/sql/item_cmpfunc.cc
|
+++ b/sql/item_cmpfunc.cc
|
@@ -471,7 +471,7 @@ static bool convert_const_to_int(THD *thd, Item_field *field_item,
|
/* Restore the original field value. */
|
if (save_field_value)
|
{
|
- result= field->store(orig_field_val, TRUE);
|
+ result= field->store(orig_field_val, field_item->unsigned_flag);
|
/* orig_field_val must be a valid value that can be restored back. */
|
DBUG_ASSERT(!result);
|
}
|
3) Placing revert replacement with integer (as vell as other types) in TABLE mem_root, which freed in CREATE TABLE earlier then runtime mem_root, which lead to attempt of accessing freed memory.
(should be decided how to fixit, taking into account 5acd391e8b2d4d760ae7f96a59413c9ea247e9b1 )
Just an additional warning. If you leave the table with the bigint on your system this can also cause crashes of MariaDB when running queries on information_schema.tables. So I would highly recommend to remove the table after testing from a staging system if you want to test something different.
Example on how to also make MariaDB crash:
Step 1: Create the table as stated above if it doesn't exist yet:
CREATE TABLE v0 ( v1 bigint CHECK ( v1 NOT IN ( 'x' , 'x111' ) ) ) ; |
You now get a signal 11 and ignore it
Step 2:
Run a query on information_schema.tables
MariaDB [(none)]> SELECT COUNT(*) FROM information_schema.tables WHERE `ENGINE` = 'InnoDB'; |
ERROR 2013 (HY000): Lost connection to MySQL server during query |
This now also causes a signal 11 with e.g. the following crash report:
220301 11:40:26 [ERROR] mysqld got signal 11 ; |
This could be because you hit a bug. It is also possible that this binary |
or one of the libraries it was linked against is corrupt, improperly built,
|
or misconfigured. This error can also be caused by malfunctioning hardware.
|
|
|
To report this bug, see https://mariadb.com/kb/en/reporting-bugs |
|
|
We will try our best to scrape up some info that will hopefully help |
diagnose the problem, but since we have already crashed,
|
something is definitely wrong and this may fail. |
|
|
Server version: 10.4.22-MariaDB-log-cll-lve |
key_buffer_size=67108864 |
read_buffer_size=1048576 |
max_used_connections=3 |
max_threads=502 |
thread_count=8 |
It is possible that mysqld could use up to
|
key_buffer_size + (read_buffer_size + sort_buffer_size)*max_threads = 1106102 K bytes of memory |
Hope that's ok; if not, decrease some variables in the equation. |
|
|
Thread pointer: 0x7f056f607988 |
Attempting backtrace. You can use the following information to find out
|
where mysqld died. If you see no messages after this, something went |
terribly wrong...
|
stack_bottom = 0x7f06312903d8 thread_stack 0x40000 |
/usr/sbin/mysqld(my_print_stacktrace+0x2e)[0x55702cb5571e] |
/usr/sbin/mysqld(handle_fatal_signal+0x54d)[0x55702c641d9d] |
sigaction.c:0(__restore_rt)[0x7f062f7c3c20] |
/usr/sbin/mysqld(_ZN16Item_change_list26rollback_item_tree_changesEv+0x21)[0x55702c3e7c61] |
/usr/sbin/mysqld(_Z11mysql_parseP3THDPcjP12Parser_statebb+0x351)[0x55702c439951] |
/usr/sbin/mysqld(_Z16dispatch_command19enum_server_commandP3THDPcjbb+0x1611)[0x55702c43bf81] |
/usr/sbin/mysqld(_Z10do_commandP3THD+0x13a)[0x55702c43d3fa] |
/usr/sbin/mysqld(_Z24do_handle_one_connectionP7CONNECT+0x26e)[0x55702c521e2e] |
/usr/sbin/mysqld(handle_one_connection+0x3d)[0x55702c521eed] |
pthread_create.c:0(start_thread)[0x7f062f7b917a] |
:0(__GI___clone)[0x7f062ebcddc3] |
|
|
Trying to get some variables.
|
Some pointers may be invalid and cause the dump to abort.
|
Query (0x7f056f6551e0): SELECT COUNT(*) FROM information_schema.tables WHERE `ENGINE` = 'InnoDB' |
|
|
Connection ID (thread ID): 10 |
Status: NOT_KILLED
|
|
|
Optimizer switch: index_merge=on,index_merge_union=on,index_merge_sort_union=on,index_merge_intersection=on,index_merge_sort_intersection=off,engine_condition_pushdown=off,index_condition_pushdown=on,derived_merge=on,derived_with_keys=on,firstmatch=on,loosescan=on,m |
aterialization=on,in_to_exists=on,semijoin=on,partial_match_rowid_merge=on,partial_match_table_scan=on,subquery_cache=on,mrr=off,mrr_cost_based=off,mrr_sort_keys=off,outer_join_with_cache=on,semijoin_with_cache=on,join_cache_incremental=on,join_cache_hashed=on,join_
|
cache_bka=on,optimize_join_buffer_size=on,table_elimination=on,extended_keys=on,exists_to_in=on,orderby_uses_equalities=on,condition_pushdown_for_derived=on,split_materialized=on,condition_pushdown_for_subquery=on,rowid_filter=on,condition_pushdown_from_having=on
|
|
|
The manual page at https://mariadb.com/kb/en/how-to-produce-a-full-stack-trace-for-mysqld/ contains |
information that should help you find out what is causing the crash.
|
Writing a core file...
|
Working directory at /var/lib/mysql
|
Resource Limits:
|
Limit Soft Limit Hard Limit Units
|
Max cpu time unlimited unlimited seconds
|
Max file size unlimited unlimited bytes
|
Max data size unlimited unlimited bytes
|
Max stack size 8388608 unlimited bytes |
Max core file size 0 unlimited bytes |
Max resident set unlimited unlimited bytes
|
Max processes 512018 512018 processes |
Max open files 51200 51200 files |
Max locked memory 65536 65536 bytes |
Max address space unlimited unlimited bytes
|
Max file locks unlimited unlimited locks
|
Max pending signals 512018 512018 signals |
Max msgqueue size 819200 819200 bytes |
Max nice priority 0 0 |
Max realtime priority 0 0 |
Max realtime timeout unlimited unlimited us
|
Core pattern: |/usr/lib/systemd/systemd-coredump %P %u %g %s %t %c %h %e
|
I hope this issue can be resolved soon as it can cause unwanted behaviour on a MariaDB server.
IMHO to fix 3) we should do correct parse/prepare/memory management:
a) During parsing only permanent arena/mem_root is active
b) during prepare (fix field & co) runtime arena is active and thd->stmt_arena points on permanent arena (now only permanent mem_root is active)
commit 16f2cf8f6fff884d75c5680230e2a54009ae5097 (HEAD > bb-10.2MDEV-25638, origin/bb-10.2-MDEV-25638)
Author: Oleksandr Byelkin <sanja@mariadb.com>
Date: Wed Apr 6 09:31:59 2022 +0200
MDEV-25638 Assertion `!result' failed in convert_const_to_int
The test suite triggers 3 bugs:
I. Absence of STATUS_NO_RECORD on an empty record
II. Mismatch signed and unsigned becaue parameter is not
taking from the item but was a constant.
III. Problem with rollback changes made for Items in the TABLE object:
A cycle of live of Items (expressions) in table is following:
1) Parsed in the query arena of the table
2) Prepared with the permanent query arena of the table be active as a
runtime and stmt (permanent) arena (here is difference from usual
execution)
3) usage (can be sorter of one query live (CREATE TABLE for example) or
longer then several queries (SELECT and using table cache), it is not a
problem because all fields are local to the table).
4) cleanup and deallocate with the TABLE object
So looking on the above all changes in the expressions belonged to
a TABLE object should be just ignored.
Thanks! I repeated on 10.2-10.5, works as expected on 5.5-10.1.
non-debug build returns just
Warning (Code 1292): Truncated incorrect DOUBLE value: 'x'
Warning (Code 1292): Truncated incorrect DOUBLE value: 'x111'
10.2 d0785f773188b5f0eebb313
#3 <signal handler called>#4 __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:50#5 0x00007f4b3561d859 in __GI_abort () at abort.c:79#6 0x00007f4b3561d729 in __assert_fail_base (fmt=0x7f4b357b3588 "%s%s%s:%u: %s%sAssertion `%s' failed.\n%n", assertion=0x55e7012c244d "!result", file=0x55e7012c2300 "/10.2/src/sql/item_cmpfunc.cc", line=476, function=<optimized out>) at assert.c:92#7 0x00007f4b3562ef36 in __GI___assert_fail (assertion=0x55e7012c244d "!result", file=0x55e7012c2300 "/10.2/src/sql/item_cmpfunc.cc", line=476, function=0x55e7012c2418 "bool convert_const_to_int(THD*, Item_field*, Item**)") at assert.c:101#8 0x000055e7009ffb2f in convert_const_to_int (thd=0x7f4ad8000d90, field_item=0x7f4ad80adbc0, item=0x7f4ad80ae7b0) at /10.2/src/sql/item_cmpfunc.cc:476#9 0x000055e700a0c9db in Item_func_in::fix_length_and_dec (this=0x7f4ad80ae670) at /10.2/src/sql/item_cmpfunc.cc:4365#10 0x000055e700a3accc in Item_func::fix_fields (this=0x7f4ad80ae670, thd=0x7f4ad8000d90, ref=0x7f4ad80ae7d0) at /10.2/src/sql/item_func.cc:230#11 0x000055e700a0bda5 in Item_func_in::fix_fields (this=0x7f4ad80ae670, thd=0x7f4ad8000d90, ref=0x7f4ad80ae7d0) at /10.2/src/sql/item_cmpfunc.cc:4125#12 0x000055e700847c96 in fix_vcol_expr (thd=0x7f4ad8000d90, vcol=0x7f4ad80ae7c0) at /10.2/src/sql/table.cc:2811#13 0x000055e7008480b5 in fix_and_check_vcol_expr (thd=0x7f4ad8000d90, table=0x7f4b30197c20, vcol=0x7f4ad80ae7c0) at /10.2/src/sql/table.cc:2896#14 0x000055e700848530 in unpack_vcol_info_from_frm (thd=0x7f4ad8000d90, mem_root=0x7f4b301986d8, table=0x7f4b30197c20, expr_str=0x7f4b30197700, vcol_ptr=0x7f4ad80adae0, error_reported=0x7f4b30197a8d) at /10.2/src/sql/table.cc:3015#15 0x000055e700841cdd in parse_vcol_defs (thd=0x7f4ad8000d90, mem_root=0x7f4b301986d8, table=0x7f4b30197c20, error_reported=0x7f4b30197a8d, mode=VCOL_INIT_DEPENDENCY_FAILURE_IS_WARNING) at /10.2/src/sql/table.cc:1107#16 0x000055e700849281 in open_table_from_share (thd=0x7f4ad8000d90, share=0x7f4b30198990, alias=0x55e7012b8a3b "", db_stat=0, prgflag=1, ha_open_flags=0, outparam=0x7f4b30197c20, is_create_table=true) at /10.2/src/sql/table.cc:3278#17 0x000055e7009cbd9b in ha_create_table (thd=0x7f4ad8000d90, path=0x7f4b3019a470 "./test/v0", db=0x7f4ad8012fa0 "test", table_name=0x7f4ad8012938 "v0", create_info=0x7f4b3019a8a0, frm=0x7f4b3019a460) at /10.2/src/sql/handler.cc:4881#18 0x000055e700861e57 in rea_create_table (thd=0x7f4ad8000d90, frm=0x7f4b3019a460, path=0x7f4b3019a470 "./test/v0", db=0x7f4ad8012fa0 "test", table_name=0x7f4ad8012938 "v0", create_info=0x7f4b3019a8a0, file=0x7f4ad8013748, no_ha_create_table=false) at /10.2/src/sql/unireg.cc:429#19 0x000055e70080bb98 in create_table_impl (thd=0x7f4ad8000d90, orig_db=0x7f4ad8012fa0 "test", orig_table_name=0x7f4ad8012938 "v0", db=0x7f4ad8012fa0 "test", table_name=0x7f4ad8012938 "v0", path=0x7f4b3019a470 "./test/v0", options=..., create_info=0x7f4b3019a8a0, alter_info=0x7f4b3019a7f0, create_table_mode=0, is_trans=0x7f4b3019a6ce, key_info=0x7f4b3019a450, key_count=0x7f4b3019a444, frm=0x7f4b3019a460) at /10.2/src/sql/sql_table.cc:5006#20 0x000055e70080c197 in mysql_create_table_no_lock (thd=0x7f4ad8000d90, db=0x7f4ad8012fa0 "test", table_name=0x7f4ad8012938 "v0", create_info=0x7f4b3019a8a0, alter_info=0x7f4b3019a7f0, is_trans=0x7f4b3019a6ce, create_table_mode=0) at /10.2/src/sql/sql_table.cc:5116#21 0x000055e70080c425 in mysql_create_table (thd=0x7f4ad8000d90, create_table=0x7f4ad8012988, create_info=0x7f4b3019a8a0, alter_info=0x7f4b3019a7f0) at /10.2/src/sql/sql_table.cc:5184#22 0x000055e70081c9af in Sql_cmd_create_table::execute (this=0x7f4ad8012968, thd=0x7f4ad8000d90) at /10.2/src/sql/sql_table.cc:11040#23 0x000055e7007446c7 in mysql_execute_command (thd=0x7f4ad8000d90) at /10.2/src/sql/sql_parse.cc:6020#24 0x000055e70074952c in mysql_parse (thd=0x7f4ad8000d90, rawbuf=0x7f4ad8012840 "CREATE TABLE v0 ( \nv1 bigint CHECK ( v1 NOT IN ( 'x' , 'x111' ) ) )", length=67, parser_state=0x7f4b3019b570, is_com_multi=false, is_next_command=false) at /10.2/src/sql/sql_parse.cc:7796#25 0x000055e700737756 in dispatch_command (command=COM_QUERY, thd=0x7f4ad8000d90, packet=0x7f4ad8008b51 "CREATE TABLE v0 ( \nv1 bigint CHECK ( v1 NOT IN ( 'x' , 'x111' ) ) ) ", packet_length=68, is_com_multi=false, is_next_command=false) at /10.2/src/sql/sql_parse.cc:1827#26 0x000055e700736251 in do_command (thd=0x7f4ad8000d90) at /10.2/src/sql/sql_parse.cc:1381#27 0x000055e70089188e in do_handle_one_connection (connect=0x55e7034758b0) at /10.2/src/sql/sql_connect.cc:1336#28 0x000055e7008915f3 in handle_one_connection (arg=0x55e7034758b0) at /10.2/src/sql/sql_connect.cc:1241#29 0x000055e7010bd1a8 in pfs_spawn_thread (arg=0x55e70345fe70) at /10.2/src/storage/perfschema/pfs.cc:1869#30 0x00007f4b35b40609 in start_thread (arg=<optimized out>) at pthread_create.c:477#31 0x00007f4b3571a293 in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:95