[MDEV-20366] Server crashes in get_current_user upon SET PASSWORD via SP Created: 2019-08-16  Updated: 2020-05-30  Resolved: 2020-05-30

Status: Closed
Project: MariaDB Server
Component/s: Authentication and Privilege System, Stored routines
Affects Version/s: 10.5
Fix Version/s: 10.5.4

Type: Bug Priority: Major
Reporter: Elena Stepanova Assignee: Alexander Barkov
Resolution: Fixed Votes: 0
Labels: regression


 Description    

CREATE USER foo@localhost;
 
CREATE  PROCEDURE pr() SET PASSWORD FOR foo@localhost = PASSWORD('x');
 
CALL pr();
 
 
 
# Cleanup
 
DROP PROCEDURE pr;
 
DROP USER foo@localhost;

10.5 6073049a

 
#3  <signal handler called>
 
#4  0x00005587a6387a11 in get_current_user (thd=0x7f4938000b10, user=0xa5a5a5a5a5a5a5a5, lock=true) at /data/src/10.5/sql/sql_acl.cc:12246
 
#5  0x00005587a636c16b in check_change_password (thd=0x7f4938000b10, user=0xa5a5a5a5a5a5a5a5) at /data/src/10.5/sql/sql_acl.cc:3679
 
#6  0x00005587a632a413 in set_var_password::check (this=0x7f49381541f0, thd=0x7f4938000b10) at /data/src/10.5/sql/set_var.cc:922
 
#7  0x00005587a6329d1a in sql_set_variables (thd=0x7f4938000b10, var_list=0x7f4938139300, free=true) at /data/src/10.5/sql/set_var.cc:733
 
#8  0x00005587a643c5cb in mysql_execute_command (thd=0x7f4938000b10) at /data/src/10.5/sql/sql_parse.cc:4924
 
#9  0x00005587a63530e5 in sp_instr_stmt::exec_core (this=0x7f4938154210, thd=0x7f4938000b10, nextp=0x7f494eccd6b4) at /data/src/10.5/sql/sp_head.cc:3606
 
#10 0x00005587a6352442 in sp_lex_keeper::reset_lex_and_exec_core (this=0x7f4938154258, thd=0x7f4938000b10, nextp=0x7f494eccd6b4, open_tables=false, instr=0x7f4938154210) at /data/src/10.5/sql/sp_head.cc:3334
 
#11 0x00005587a6352c8a in sp_instr_stmt::execute (this=0x7f4938154210, thd=0x7f4938000b10, nextp=0x7f494eccd6b4) at /data/src/10.5/sql/sp_head.cc:3512
 
#12 0x00005587a634c86c in sp_head::execute (this=0x7f4938153458, thd=0x7f4938000b10, merge_da_on_success=true) at /data/src/10.5/sql/sp_head.cc:1346
 
#13 0x00005587a634f1e3 in sp_head::execute_procedure (this=0x7f4938153458, thd=0x7f4938000b10, args=0x7f49380058f8) at /data/src/10.5/sql/sp_head.cc:2288
 
#14 0x00005587a6435f8d in do_execute_sp (thd=0x7f4938000b10, sp=0x7f4938153458) at /data/src/10.5/sql/sql_parse.cc:3019
 
#15 0x00005587a6436b80 in Sql_cmd_call::execute (this=0x7f4938013458, thd=0x7f4938000b10) at /data/src/10.5/sql/sql_parse.cc:3261
 
#16 0x00005587a6441562 in mysql_execute_command (thd=0x7f4938000b10) at /data/src/10.5/sql/sql_parse.cc:6075
 
#17 0x00005587a64467fc in mysql_parse (thd=0x7f4938000b10, rawbuf=0x7f49380133a8 "CALL pr()", length=9, parser_state=0x7f494eccf170, is_com_multi=false, is_next_command=false) at /data/src/10.5/sql/sql_parse.cc:7884
 
#18 0x00005587a6432b88 in dispatch_command (command=COM_QUERY, thd=0x7f4938000b10, packet=0x7f4938008341 "CALL pr()", packet_length=9, is_com_multi=false, is_next_command=false) at /data/src/10.5/sql/sql_parse.cc:1843
 
#19 0x00005587a64312ce in do_command (thd=0x7f4938000b10) at /data/src/10.5/sql/sql_parse.cc:1360
 
#20 0x00005587a65be30a in do_handle_one_connection (connect=0x5587a8e3cbf0, put_in_cache=true) at /data/src/10.5/sql/sql_connect.cc:1414
 
#21 0x00005587a65be039 in handle_one_connection (arg=0x5587a8e3cbf0) at /data/src/10.5/sql/sql_connect.cc:1309
 
#22 0x00005587a6ac1beb in pfs_spawn_thread (arg=0x5587a8da67a0) at /data/src/10.5/storage/perfschema/pfs.cc:1862
 
#23 0x00007f495a6804a4 in start_thread (arg=0x7f494ecd0700) at pthread_create.c:456
 
#24 0x00007f4958bc8d0f in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:97

Both debug and release builds crash.

The problem appeared in 10.5 tree with this commit:

commit bf5a144e1692f6cc6a6d781b7e75ff4abf32bdf3
 
Author: Alexander Barkov
 
Date:   Fri May 31 16:44:17 2019 +0400
 
 
 
    MDEV-19639 + MDEV-19640 fix + preparatory changes for WL#4179
 
...



 Comments   
Comment by Elena Stepanova [ 2020-04-06 ]

A somewhat different stack trace has been observed in very similar scenarios on current non-debug 10.5 builds. It happens with the same test cases which normally produce the stack trace from the description, but every now and then they end up with this one:

10.5 non-debug 13911752

 
#3  <signal handler called>
 
#4  __strcmp_sse2_unaligned () at ../sysdeps/x86_64/multiarch/strcmp-sse2-unaligned.S:32
 
#5  0x00005581ee25d1af in find_first_user<ACL_USER> (arr=arr@entry=0x7f65a80f9358, len=len@entry=11, user=user@entry=0x0) at /data/src/10.5/sql/sql_acl.cc:2949
 
#6  0x00005581ee25d27d in find_first_user<ACL_USER> (user=0x0, len=11, arr=<optimized out>) at /data/src/10.5/sql/sql_acl.cc:2963
 
#7  acl_find_user_by_name (user=0x0) at /data/src/10.5/sql/sql_acl.cc:2963
 
#8  find_user_exact (host=0xffffffff00000000 <error: Cannot access memory at address 0xffffffff00000000>, user=0x0) at /data/src/10.5/sql/sql_acl.cc:4132
 
#9  0x00005581ee262931 in change_password (thd=thd@entry=0x7f65a80009b8, user=0x7f65a80ef840) at /data/src/10.5/sql/sql_acl.cc:3848
 
#10 0x00005581ee237397 in set_var_password::update (this=<optimized out>, thd=0x7f65a80009b8) at /data/src/10.5/sql/set_var.cc:955
 
#11 0x00005581ee239389 in sql_set_variables (thd=thd@entry=0x7f65a80009b8, var_list=var_list@entry=0x7f65a80ef958, free=free@entry=true) at /data/src/10.5/sql/set_var.cc:746
 
#12 0x00005581ee2de556 in mysql_execute_command (thd=0x7f65a80009b8) at /data/src/10.5/sql/sql_parse.cc:4976
 
#13 0x00005581ee24ad24 in sp_instr_stmt::exec_core (this=0x7f65a80fad28, thd=<optimized out>, nextp=0x7f65bab72414) at /data/src/10.5/sql/sp_head.cc:3761
 
#14 0x00005581ee252751 in sp_lex_keeper::reset_lex_and_exec_core (this=this@entry=0x7f65a80fad70, thd=thd@entry=0x7f65a80009b8, nextp=nextp@entry=0x7f65bab72414, open_tables=open_tables@entry=false, instr=instr@entry=0x7f65a80fad28) at /data/src/10.5/sql/sp_head.cc:3488
 
#15 0x00005581ee253259 in sp_instr_stmt::execute (this=0x7f65a80fad28, thd=0x7f65a80009b8, nextp=0x7f65bab72414) at /data/src/10.5/sql/sp_head.cc:3667
 
#16 0x00005581ee24e5db in sp_head::execute (this=this@entry=0x7f65a80f9d30, thd=thd@entry=0x7f65a80009b8, merge_da_on_success=merge_da_on_success@entry=true) at /data/src/10.5/sql/sp_head.cc:1432
 
#17 0x00005581ee24fa8b in sp_head::execute_procedure (this=0x7f65a80f9d30, thd=thd@entry=0x7f65a80009b8, args=0x7f65a80056c8) at /data/src/10.5/sql/sp_head.cc:2442
 
#18 0x00005581ee2d925f in do_execute_sp (thd=0x7f65a80009b8, sp=<optimized out>) at /data/src/10.5/sql/sql_parse.cc:3013
 
#19 0x00005581ee2e85c6 in Sql_cmd_call::execute (this=this@entry=0x7f65a80103c8, thd=thd@entry=0x7f65a80009b8) at /data/src/10.5/sql/sql_parse.cc:3258
 
#20 0x00005581ee2d978a in Sql_cmd_call::execute (this=0x7f65a80103c8, thd=0x7f65a80009b8) at /data/src/10.5/sql/sql_parse.cc:3212
 
#21 0x00005581ee2dae1d in mysql_execute_command (thd=thd@entry=0x7f65a80009b8) at /data/src/10.5/sql/sql_parse.cc:5908
 
#22 0x00005581ee2e250b in mysql_parse (thd=thd@entry=0x7f65a80009b8, rawbuf=<optimized out>, length=17, parser_state=parser_state@entry=0x7f65bab73550, is_com_multi=is_com_multi@entry=false, is_next_command=is_next_command@entry=false) at /data/src/10.5/sql/sql_parse.cc:7953
 
#23 0x00005581ee2d7b3f in dispatch_command (command=command@entry=COM_QUERY, thd=thd@entry=0x7f65a80009b8, packet=packet@entry=0x7f65a8007c69 "CALL  sp_grammar3", packet_length=packet_length@entry=17, is_com_multi=is_com_multi@entry=false, is_next_command=is_next_command@entry=false) at /data/src/10.5/sql/sql_parse.cc:1840
 
#24 0x00005581ee2d5faa in do_command (thd=0x7f65a80009b8) at /data/src/10.5/sql/sql_parse.cc:1359
 
#25 0x00005581ee3be564 in do_handle_one_connection (connect=<optimized out>, connect@entry=0x5581f1751a58, put_in_cache=put_in_cache@entry=true) at /data/src/10.5/sql/sql_connect.cc:1422
 
#26 0x00005581ee3be863 in handle_one_connection (arg=arg@entry=0x5581f1751a58) at /data/src/10.5/sql/sql_connect.cc:1319
 
#27 0x00005581ee6d8634 in pfs_spawn_thread (arg=0x5581f174e188) at /data/src/10.5/storage/perfschema/pfs.cc:2201
 
#28 0x00007f65c1f604a4 in start_thread (arg=0x7f65bab74700) at pthread_create.c:456
 
#29 0x00007f65c0094d0f in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:97

Comment by Alexander Barkov [ 2020-05-30 ]

The problem is repeatable even without the CREATE USER statement:

CREATE OR REPLACE PROCEDURE p1() SET PASSWORD FOR foo@localhost = PASSWORD('x');
 
CALL p1();

Comment by Alexander Barkov [ 2020-05-30 ]

Was introduced by this commit:

commit bf5a144e1692f6cc6a6d781b7e75ff4abf32bdf3
 
Author: Alexander Barkov <bar@mariadb.com>  2019-05-31 16:44:17
 
 
 
    MDEV-19639 + MDEV-19640 fix + preparatory changes for WL#4179

Generated at Thu Feb 08 08:58:55 UTC 2024 using Jira 8.20.16#820016-sha1:9d11dbea5f4be3d4cc21f03a88dd11d8c8687422.