[MDEV-22356] ASAN heap-use-after-free in _ma_get_status on ALTER with concurrent locks Created: 2020-04-23  Updated: 2023-07-28  Resolved: 2023-07-28

Status: Closed
Project: MariaDB Server
Component/s: Locking, Storage Engine - Aria
Affects Version/s: 10.1
Fix Version/s: N/A

Type: Bug Priority: Minor
Reporter: Elena Stepanova Assignee: Michael Widenius
Resolution: Won't Fix Votes: 0
Labels: not-10.2, not-10.3, not-10.4, not-10.5


 Description   

Since it's a 10.1-only problem, I don't expect it to be fixed, just need it to be filed.

CREATE TABLE t1 (a INT) ENGINE Aria ROW_FORMAT DYNAMIC;
 
INSERT INTO t1 () VALUES ();
 
LOCK TABLES t1 WRITE CONCURRENT, t1 AS x WRITE;
 
 
 
--connect (con1,localhost,root,,test)
 
--send
 
  ALTER TABLE t1 ADD COLUMN f INT, LOCK=EXCLUSIVE;
 
 
 
--connection default
 
UNLOCK TABLES;
 
--connection con1
 
--reap
 
--disconnect con1
 
--connection default
 
DROP TABLE t1;

10.1 ad4b7056

 
==4889==ERROR: AddressSanitizer: heap-use-after-free on address 0x6290000fa2b0 at pc 0x55ef9cad5a26 bp 0x7f6da9578380 sp 0x7f6da9578378
 
READ of size 8 at 0x6290000fa2b0 thread T7
 
    #0 0x55ef9cad5a25 in _ma_get_status /data/src/10.1/storage/maria/ma_state.c:293
 
    #1 0x55ef9d5765d9 in thr_lock /data/src/10.1/mysys/thr_lock.c:838
 
    #2 0x55ef9d5765d9 in thr_multi_lock /data/src/10.1/mysys/thr_lock.c:1291
 
    #3 0x55ef9c8b6b9a in mysql_lock_tables(THD*, st_mysql_lock*, unsigned int) /data/src/10.1/sql/lock.cc:320
 
    #4 0x55ef9c8b985d in mysql_lock_tables(THD*, TABLE**, unsigned int, unsigned int) /data/src/10.1/sql/lock.cc:275
 
    #5 0x55ef9bee7523 in lock_tables(THD*, TABLE_LIST*, unsigned int, unsigned int) /data/src/10.1/sql/sql_base.cc:5557
 
    #6 0x55ef9c242910 in mysql_alter_table(THD*, char*, char*, HA_CREATE_INFO*, TABLE_LIST*, Alter_info*, unsigned int, st_order*, bool) /data/src/10.1/sql/sql_table.cc:9136
 
    #7 0x55ef9c379513 in Sql_cmd_alter_table::execute(THD*) /data/src/10.1/sql/sql_alter.cc:334
 
    #8 0x55ef9c015ba3 in mysql_execute_command(THD*) /data/src/10.1/sql/sql_parse.cc:5442
 
    #9 0x55ef9c01a75a in mysql_parse(THD*, char*, unsigned int, Parser_state*) /data/src/10.1/sql/sql_parse.cc:7209
 
    #10 0x55ef9c022246 in dispatch_command(enum_server_command, THD*, char*, unsigned int) /data/src/10.1/sql/sql_parse.cc:1499
 
    #11 0x55ef9c0285e7 in do_command(THD*) /data/src/10.1/sql/sql_parse.cc:1131
 
    #12 0x55ef9c36d6b3 in do_handle_one_connection(THD*) /data/src/10.1/sql/sql_connect.cc:1331
 
    #13 0x55ef9c36ddaf in handle_one_connection /data/src/10.1/sql/sql_connect.cc:1242
 
    #14 0x55ef9ce08b4d in pfs_spawn_thread /data/src/10.1/storage/perfschema/pfs.cc:1868
 
    #15 0x7f6db474cfa2 in start_thread /build/glibc-vjB4T1/glibc-2.28/nptl/pthread_create.c:486
 
    #16 0x7f6db40574ce in clone (/lib/x86_64-linux-gnu/libc.so.6+0xf94ce)
 
 
 
0x6290000fa2b0 is located 176 bytes inside of 18388-byte region [0x6290000fa200,0x6290000fe9d4)
 
freed by thread T7 here:
 
    #0 0x7f6db484efb0 in __interceptor_free (/lib/x86_64-linux-gnu/libasan.so.5+0xe8fb0)
 
    #1 0x55ef9d58a8a6 in free_memory /data/src/10.1/mysys/safemalloc.c:276
 
 
 
previously allocated by thread T6 here:
 
    #0 0x7f6db484f330 in __interceptor_malloc (/lib/x86_64-linux-gnu/libasan.so.5+0xe9330)
 
    #1 0x55ef9d58a9c0 in sf_malloc /data/src/10.1/mysys/safemalloc.c:115
 
    #2 0x55ef9d75f44b  (/data/bld/10.1-asan/bin/mysqld+0x219b44b)
 
 
 
Thread T7 created by T0 here:
 
    #0 0x7f6db47b6db0 in __interceptor_pthread_create (/lib/x86_64-linux-gnu/libasan.so.5+0x50db0)
 
    #1 0x55ef9ce1541c in spawn_thread_v1 /data/src/10.1/storage/perfschema/pfs.cc:1918
 
 
 
Thread T6 created by T0 here:
 
    #0 0x7f6db47b6db0 in __interceptor_pthread_create (/lib/x86_64-linux-gnu/libasan.so.5+0x50db0)
 
    #1 0x55ef9ce1541c in spawn_thread_v1 /data/src/10.1/storage/perfschema/pfs.cc:1918
 
 
 
SUMMARY: AddressSanitizer: heap-use-after-free /data/src/10.1/storage/maria/ma_state.c:293 in _ma_get_status
 
Shadow bytes around the buggy address:
 
  0x0c5280017400: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
 
  0x0c5280017410: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
 
  0x0c5280017420: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
 
  0x0c5280017430: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
 
  0x0c5280017440: fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd
 
=>0x0c5280017450: fd fd fd fd fd fd[fd]fd fd fd fd fd fd fd fd fd
 
  0x0c5280017460: fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd
 
  0x0c5280017470: fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd
 
  0x0c5280017480: fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd
 
  0x0c5280017490: fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd
 
  0x0c52800174a0: fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd
 
Shadow byte legend (one shadow byte represents 8 application bytes):
 
  Addressable:           00
 
  Partially addressable: 01 02 03 04 05 06 07 
  Heap left redzone:       fa
 
  Freed heap region:       fd
 
  Stack left redzone:      f1
 
  Stack mid redzone:       f2
 
  Stack right redzone:     f3
 
  Stack after return:      f5
 
  Stack use after scope:   f8
 
  Global redzone:          f9
 
  Global init order:       f6
 
  Poisoned by user:        f7
 
  Container overflow:      fc
 
  Array cookie:            ac
 
  Intra object redzone:    bb
 
  ASan internal:           fe
 
  Left alloca redzone:     ca
 
  Right alloca redzone:    cb
 
==4889==ABORTING

Not reproducible on 10.2+.
No obvious effect on a non-ASAN builds.

 Comments   
Comment by Elena Stepanova [ 2023-07-28 ]

10.1 is EOL

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