[MDEV-8106] MariaDB 10.0 and 10.1 crash Created: 2015-05-05  Updated: 2019-07-12  Resolved: 2015-05-05

Status: Closed
Project: MariaDB Server
Component/s: Data Manipulation - Subquery
Affects Version/s: 5.5, 10.0, 10.1
Fix Version/s: 5.5.43, 10.0.18, 10.1.5

Type: Bug Priority: Major
Reporter: Oli Sennhauser Assignee: Oleksandr Byelkin
Resolution: Fixed Votes: 0
Labels: verified
Environment:

linux ubuntu 14.04


Attachments: File crash.sql    
Issue Links:
Duplicate
duplicates MDEV-7613 MariaDB 5.5.40 server crash on update... Closed
duplicates MDEV-7892 server crash on updates with joins Closed
Relates
relates to MDEV-20041 MariaDB Error Log Content Closed

 Description   

MySQL Server crashes on a (wrong) Query. This is considered a security bug because it can be used as DOS.

See test case and query

Reproduce: mysql -u root < crash.sql
then run query

crash mariadb 10.0.17
not crash mariadb 5.5.34
crashes mariadb 10.1.2 and 10.1.4

disabling mariadb optimizer features did not help. MySQL is not affected.

grant all on *.* to root@'%';
use d1
UPDATE tab1 t,
 (
        SELECT
                m.PAID,
                m.aktuelleaktion 
        FROM
                tab1 t1
        LEFT JOIN tab2 m ON t1.PAID = m.PAID
        WHERE
                t1.PDID = 623
        AND t1.PAID > 0
        AND t1.AKTIONSID = 0
) sel
SET t.AKTIONSID = sel.aktuelleaktion
WHERE
        t.PDID = 623
AND t.PAID = sel.PAID
;

Thread pointer: 0x0x7f72cb2b9008
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 = 0x7f72db623e50 thread_stack 0x48000
mysys/stacktrace.c:247(my_print_stacktrace)[0xbc4eee]
sql/signal_handler.cc:153(handle_fatal_signal)[0x71c4dc]
/lib/x86_64-linux-gnu/libpthread.so.0(+0x10340)[0x7f72db2cc340]
sql/opt_subselect.cc:3294(fix_semijoin_strategies_for_picked_join_order(JOIN*))[0x6ae549]
sql/sql_list.h:34(Sql_alloc::operator new(unsigned long))[0x5cbf5a]
sql/sql_select.cc:4072(make_join_statistics)[0x5e545b]
sql/sql_select.cc:1339(JOIN::optimize_inner())[0x5e7a9a]
sql/sql_select.cc:1037(JOIN::optimize())[0x5ea7fb]
sql/sql_derived.cc:804(mysql_derived_optimize(THD*, LEX*, TABLE_LIST*))[0x5752bd]
sql/sql_derived.cc:192(mysql_handle_single_derived(LEX*, TABLE_LIST*, unsigned int))[0x574b9a]
sql/table.cc:6915(TABLE_LIST::handle_derived(LEX*, unsigned int))[0x638e6a]
sql/sql_lex.cc:3550(st_select_lex::handle_derived(LEX*, unsigned int))[0x587090]
sql/sql_select.cc:1082(JOIN::optimize_inner())[0x5e7418]
sql/sql_select.cc:1037(JOIN::optimize())[0x5eaa22]
sql/sql_update.cc:1570(mysql_multi_update(THD*, TABLE_LIST*, List<Item>*, List<Item>*, Item*, unsigned long long, enum_duplicates, bool, st_select_lex_unit*, st_select_lex*, multi_update**))[0x62f64c]
sql/sql_parse.cc:3367(mysql_execute_command(THD*))[0x59beb8]
sql/sql_parse.cc:6517(mysql_parse(THD*, char*, unsigned int, Parser_state*))[0x59d8ea]
sql/sql_parse.cc:1302(dispatch_command(enum_server_command, THD*, char*, unsigned int))[0x59f757]
sql/sql_parse.cc:996(do_command(THD*))[0x59fe68]
sql/sql_connect.cc:1375(do_handle_one_connection(THD*))[0x6692b4]
sql/sql_connect.cc:1291(handle_one_connection)[0x6693f2]
/lib/x86_64-linux-gnu/libpthread.so.0(+0x8182)[0x7f72db2c4182]
/lib/x86_64-linux-gnu/libc.so.6(clone+0x6d)[0x7f72da1a047d]
 
Trying to get some variables.
Some pointers may be invalid and cause the dump to abort.
Query (0x7f72b5822020): UPDATE tab1 t,  (         SELECT                 m.PAID,                 m.aktuelleaktion          FROM                 tab1 t1         LEFT JOIN tab2 m ON t1.PAID = m.PAID         WHERE                 t1.PDID = 623         AND t1.PAID > 0         AND t1.AKTIONSID = 0 ) sel SET t.AKTIONSID = sel.aktuelleaktion WHERE         t.PDID = 623 AND t.PAID = sel.PAID
Connection ID (thread ID): 5
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,materialization=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=off,table_elimination=on,extended_keys=on,exists_to_in=on



 Comments   
Comment by Elena Stepanova [ 2015-05-05 ]

It's the bug MDEV-7613 which was fixed in 5.5.43 and the bugfix will be merged into next releases of 10.0 and 10.1.
I checked that the provided test case fails on 5.5.42, and stops failing after applying the patch for MDEV-7613.

Generated at Thu Feb 08 07:24:41 UTC 2024 using Jira 8.20.16#820016-sha1:9d11dbea5f4be3d4cc21f03a88dd11d8c8687422.