[MDEV-22133] handle_fatal_signal (sig=11) on optimized builds in handle_grant_table instead of ERROR | Buffer overflow (on optimized builds) Created: 2020-04-03  Updated: 2023-04-27

Status: Stalled
Project: MariaDB Server
Component/s: Authentication and Privilege System
Affects Version/s: 10.1, 10.2, 10.3, 10.4, 10.5
Fix Version/s: 10.4, 10.5

Type: Bug Priority: Major
Reporter: Roel Van de Paar Assignee: Oleksandr Byelkin
Resolution: Unresolved Votes: 0
Labels: affects-tests, regression-10.5, security

Issue Links:
Duplicate
is duplicated by MDEV-22319 SIGSEGV in handle_grant_table Closed

 Description    

RENAME TABLE mysql.procs_priv TO mysql.procs_gone;
 
CREATE USER a@localhost;

Leads to:

10.5.3 e8351934b68d6d3ee273292eaa2ece203bb2b846

 
Core was generated by `/data/MD020420-mariadb-10.5.3-linux-x86_64-opt/bin/mysqld --no-defaults --core-'.
 
Program terminated with signal SIGSEGV, Segmentation fault.
 
#0  __pthread_kill (threadid=<optimized out>, signo=signo@entry=11)
 
    at ../sysdeps/unix/sysv/linux/pthread_kill.c:57
 
[Current thread is 1 (Thread 0x7f5543691700 (LWP 13792))]
 
(gdb) bt
 
#0  __pthread_kill (threadid=<optimized out>, signo=signo@entry=11) at ../sysdeps/unix/sysv/linux/pthread_kill.c:57
 
#1  0x000055ff22880d47 in my_write_core (sig=sig@entry=11) at /data/10.5_opt/mysys/stacktrace.c:518
 
#2  0x000055ff2224287a in handle_fatal_signal (sig=11) at /data/10.5_opt/sql/signal_handler.cc:325
 
#3  <signal handler called>
 
#4  handle_grant_table (thd=0x7f5515c12018, grant_table=..., which_table=PROCS_PRIV_TABLE, drop=false, user_from=0x7f5515c470d8, user_to=0x0) at /data/10.5_opt/sql/sql_acl.cc:9895
 
#5  0x000055ff21fce319 in handle_grant_data (thd=thd@entry=0x7f5515c12018, tables=..., drop=drop@entry=false, user_from=user_from@entry=0x7f5515c470d8, user_to=0x0) at /data/10.5_opt/sql/sql_acl.cc:10464
 
#6  0x000055ff21fd168c in mysql_create_user (thd=thd@entry=0x7f5515c12018, list=..., handle_as_role=false) at /data/10.5_opt/sql/sql_acl.cc:10680
 
#7  0x000055ff2204df10 in mysql_execute_command (thd=thd@entry=0x7f5515c12018) at /data/10.5_opt/sql/sql_parse.cc:5247
 
#8  0x000055ff22054a6c in mysql_parse (thd=thd@entry=0x7f5515c12018, rawbuf=<optimized out>, length=23, parser_state=parser_state@entry=0x7f55436904d0, is_com_multi=is_com_multi@entry=false, is_next_command=is_next_command@entry=false) at /data/10.5_opt/sql/sql_parse.cc:7953
 
#9  0x000055ff220498e0 in dispatch_command (command=command@entry=COM_QUERY, thd=thd@entry=0x7f5515c12018, packet=packet@entry=0x7f5515c3a019 "CREATE USER a@localhost", packet_length=packet_length@entry=23, is_com_multi=is_com_multi@entry=false, is_next_command=is_next_command@entry=false) at /data/10.5_opt/sql/sql_parse.cc:1839
 
#10 0x000055ff22047bff in do_command (thd=0x7f5515c12018) at /data/10.5_opt/sql/sql_parse.cc:1358
 
#11 0x000055ff2213c92e in do_handle_one_connection (connect=<optimized out>, connect@entry=0x7f55410329b8, put_in_cache=put_in_cache@entry=true) at /data/10.5_opt/sql/sql_connect.cc:1422
 
#12 0x000055ff2213cad4 in handle_one_connection (arg=arg@entry=0x7f55410329b8) at /data/10.5_opt/sql/sql_connect.cc:1319
 
#13 0x000055ff224a89da in pfs_spawn_thread (arg=0x7f554104b018) at /data/10.5_opt/storage/perfschema/pfs.cc:2201
 
#14 0x00007f5542ab86db in start_thread (arg=0x7f5543691700) at pthread_create.c:463
 
#15 0x00007f5541eb688f in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:95

Bug confirmed present in:
MariaDB: 10.1.45 (dbg), 10.1.45 (opt), 10.2.32 (dbg), 10.2.32 (opt), 10.3.23 (dbg), 10.3.23 (opt), 10.4.13 (dbg), 10.4.13 (opt), 10.5.3 (dbg), 10.5.3 (opt)

Bug confirmed not present in:

MySQL: 5.5.62 (dbg), 5.5.62 (opt), 5.6.47 (dbg), 5.6.47 (opt), 5.7.29 (dbg), 5.7.29 (opt), 8.0.19 (dbg), 8.0.19 (opt)

Output of MySQL 5.6.47;

5.6.47>RENAME TABLE mysql.procs_priv TO mysql.procs_gone;
 
Query OK, 0 rows affected (0.00 sec)
 
5.6.47>CREATE USER a@localhost;
 
ERROR 1146 (42S02): Table 'mysql.procs_priv' doesn't exist



 Comments   
Comment by Roel Van de Paar [ 2020-04-21 ]

MDEV-22319 was marked as duplicate of this ticket and closed as duplicate. Same issue.

Comment by Roel Van de Paar [ 2020-05-04 ]

Additional testcases

RENAME TABLE mysql.procs_priv TO mysql.procs_priv_backup;
 
DROP USER a;


RENAME TABLE mysql.procs_priv TO procs_priv_backup;
 
RENAME USER '0'@'0' to '0'@'0';

4 Slightly different stacks. Unique Bug ID's;

SIGSEGV|handle_grant_table|handle_grant_data|mysql_create_user|mysql_execute_command
 
SIGSEGV|handle_grant_table|handle_grant_data|mysql_drop_user|mysql_execute_command
 
SIGSEGV|handle_grant_table|handle_grant_data|mysql_rename_user|mysql_execute_command
 
SIGABRT|handle_grant_table|handle_grant_data|mysql_create_user|mysql_execute_command  # Ref below

Comment by Roel Van de Paar [ 2020-06-15 ]

New developments in latest 10.5 branch. This testcase:

USE test;
 
CREATE TABLE t (c1 SMALLINT(254),c2 BIGINT(254),c3 DECIMAL(65,30) ZEROFILL) ENGINE=MyISAM PARTITION BY HASH((c1)) PARTITIONS 852;
 
INSERT INTO t VALUES ('','','');
 
RENAME TABLE mysql.procs_priv TO procs_priv_backup;
 
CREATE USER 'test_user'@'localhost';

Leads to:

10.5.4 4080e3acefd7e58d88c2f3539fb6a0fb359cf057 (opt)

 
10.5.4>USE test;
 
Database changed
 
10.5.4>CREATE TABLE t (c1 SMALLINT(254),c2 BIGINT(254),c3 DECIMAL(65,30) ZEROFILL) ENGINE=MyISAM PARTITION BY HASH((c1)) PARTITIONS 852;
 
Query OK, 0 rows affected (0.085 sec)
 
10.5.4>INSERT INTO t VALUES ('','','');
 
ERROR 1366 (22007): Incorrect integer value: '' for column `test`.`t`.`c1` at row 1
 
10.5.4>RENAME TABLE mysql.procs_priv TO procs_priv_backup;
 
Query OK, 0 rows affected (0.009 sec)
 
10.5.4>CREATE USER 'test_user'@'localhost';
 
*** buffer overflow detected ***: /test/MD150620-mariadb-10.5.4-linux-x86_64-opt/bin/mysqld terminated ***

Additionally (besides the buffer overflow), a new SIGABRT not seen before is showing up, which at the same time is also an oddity, as GDB states;

10.5.4 4080e3acefd7e58d88c2f3539fb6a0fb359cf057

 
Program terminated with signal SIGABRT, Aborted.

While the error log states;

10.5.4 4080e3acefd7e58d88c2f3539fb6a0fb359cf057

 
200616  0:08:27 [ERROR] mysqld got signal 11 ;

Perhaps the server aborted during crash reporting, perhaps as a result of the buffer overflow. Full stack:

10.5.4 4080e3acefd7e58d88c2f3539fb6a0fb359cf057

 
Core was generated by `/test/MD150620-mariadb-10.5.4-linux-x86_64-opt/bin/mysqld --no-defaults --core-'.
 
Program terminated with signal SIGABRT, Aborted.
 
#0  __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:51
 
[Current thread is 1 (Thread 0x146650714700 (LWP 1458337))]
 
#0  __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:51
 
#1  0x000014664e9aa8db in __GI_abort () at abort.c:100
 
#2  0x000014664e9f3897 in __libc_message (action=action@entry=(do_abort | do_backtrace), 
    fmt=fmt@entry=0x14664eb20988 "*** %s ***: %s terminated\n") at ../sysdeps/posix/libc_fatal.c:181
 
#3  0x000014664ea9ecff in __GI___fortify_fail_abort (need_backtrace=need_backtrace@entry=true, 
    msg=msg@entry=0x14664eb20905 "buffer overflow detected") at fortify_fail.c:33
 
#4  0x000014664ea9ed21 in __GI___fortify_fail (msg=msg@entry=0x14664eb20905 "buffer overflow detected")
 
    at fortify_fail.c:44
 
#5  0x000014664ea9ca10 in __GI___chk_fail () at chk_fail.c:28
 
#6  0x000014664ea9ec0a in __fdelt_chk (d=<optimized out>) at fdelt_chk.c:25
 
#7  0x000056411cbadfa5 in addr_resolve (loc=0x146650711580, ptr=<optimized out>)
 
    at /test/10.5_opt/mysys/my_addr_resolve.c:232
 
#8  my_addr_resolve (ptr=<optimized out>, loc=loc@entry=0x146650711580)
 
    at /test/10.5_opt/mysys/my_addr_resolve.c:313
 
#9  0x000056411cb92553 in print_with_addr_resolve (n=<optimized out>, addrs=0x1466507115a0)
 
    at /test/10.5_opt/mysys/stacktrace.c:291
 
#10 my_print_stacktrace (stack_bottom=<optimized out>, thread_stack=<optimized out>, 
    silent=silent@entry=0 '\000') at /test/10.5_opt/mysys/stacktrace.c:310
 
#11 0x000056411c55bf85 in handle_fatal_signal (sig=11) at /test/10.5_opt/sql/signal_handler.cc:208
 
#12 <signal handler called>
 
#13 handle_grant_table (thd=0x146629012018, grant_table=..., which_table=PROCS_PRIV_TABLE, drop=false, 
    user_from=0x146629047100, user_to=0x0) at /test/10.5_opt/sql/sql_acl.cc:9949
 
#14 0x000056411c2e5779 in handle_grant_data (thd=thd@entry=0x146629012018, tables=..., 
    drop=drop@entry=false, user_from=user_from@entry=0x146629047100, user_to=0x0)
 
    at /test/10.5_opt/sql/sql_acl.cc:10518
 
#15 0x000056411c2e8aec in mysql_create_user (thd=thd@entry=0x146629012018, list=..., 
    handle_as_role=false) at /test/10.5_opt/sql/sql_acl.cc:10734
 
#16 0x000056411c36464a in mysql_execute_command (thd=thd@entry=0x146629012018)
 
    at /test/10.5_opt/sql/sql_parse.cc:5288
 
#17 0x000056411c36b85c in mysql_parse (thd=0x146629012018, rawbuf=<optimized out>, length=35, 
    parser_state=0x146650713430, is_com_multi=<optimized out>, is_next_command=<optimized out>)
 
    at /test/10.5_opt/sql/sql_parse.cc:7993
 
#18 0x000056411c360b65 in dispatch_command (command=command@entry=COM_QUERY, 
    thd=thd@entry=0x146629012018, 
    packet=packet@entry=0x14662903a019 "create user 'test_user'@'localhost'", 
    packet_length=packet_length@entry=35, is_com_multi=is_com_multi@entry=false, 
    is_next_command=is_next_command@entry=false) at /test/10.5_opt/sql/sql_parse.cc:1874
 
#19 0x000056411c35ef74 in do_command (thd=0x146629012018) at /test/10.5_opt/sql/sql_parse.cc:1355
 
#20 0x000056411c454b51 in do_handle_one_connection (connect=<optimized out>, 
    connect@entry=0x14664d433958, put_in_cache=put_in_cache@entry=true)
 
    at /test/10.5_opt/sql/sql_connect.cc:1411
 
#21 0x000056411c454eb4 in handle_one_connection (arg=arg@entry=0x14664d433958)
 
    at /test/10.5_opt/sql/sql_connect.cc:1313
 
#22 0x000056411c7c3bca in pfs_spawn_thread (arg=0x14664d44f218)
 
    at /test/10.5_opt/storage/perfschema/pfs.cc:2201
 
#23 0x000014664f68d6db in start_thread (arg=0x146650714700) at pthread_create.c:463
 
#24 0x000014664ea8b88f in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:95

It is perceivable that the high number of partitions issue can also be created outside of this handle_grant_table related scenario/code path.

Comment by Roel Van de Paar [ 2020-06-15 ]

Please also test with this testcase

USE test;
 
CREATE TABLE t2 (c1 SMALLINT(254),c2 BIGINT(254),c3 DECIMAL(65,30) ZEROFILL) ENGINE=MyISAM PARTITION BY HASH((c1)) PARTITIONS 852;
 
INSERT INTO t2 VALUES  ('aaa','aaa','aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa');
 
RENAME TABLE mysql.procs_priv TO procs_priv_backup;
 
create user 'test_user'@'localhost';

Comment by Oleksandr Byelkin [ 2021-09-16 ]

If rename (for example ) mysql.db, it will be noticed on opening, with mysql.procs_priv somehow it does not happening

Comment by Oleksandr Byelkin [ 2022-06-24 ] 

commit 3f9e6c9c1115179a6551fcca9c4b46da1b7954b8 (HEAD -> bb-10.3-MDEV-22133, origin/bb-10.3-MDEV-22133)
 
Author: Oleksandr Byelkin <sanja@mariadb.com>
 
Date:   Fri Jun 24 11:55:42 2022 +0200
 
 
 
    MDEV-22133 handle_fatal_signal (sig=11) on optimized builds in handle_grant_table instead of ERROR | Buffer overflow (on optimized builds)
 
    
    Return an error if we can not read a table required for ACL.

Generated at Thu Feb 08 09:12:26 UTC 2024 using Jira 8.20.16#820016-sha1:9d11dbea5f4be3d4cc21f03a88dd11d8c8687422.