[MDEV-23812] ASAN global-buffer-overflow in get_constant_key_infix upon SELECT DISTINCT Created: 2020-09-24  Updated: 2023-11-28

Status: Confirmed
Project: MariaDB Server
Component/s: Optimizer
Affects Version/s: 10.1, 10.2, 10.3, 10.4, 10.5, 10.6, 10.7, 10.8, 10.9, 10.10
Fix Version/s: 10.4, 10.5, 10.6

Type: Bug Priority: Major
Reporter: Elena Stepanova Assignee: Sergei Petrunia
Resolution: Unresolved Votes: 0
Labels: None


 Description   

CREATE TABLE t1 (a INT, b BINARY(64), KEY(a,b));
INSERT INTO t1 VALUES (1,'foo'),(2,'bar');
SELECT DISTINCT a FROM t1 WHERE b IS NULL OR b < 'baz';
 
# Cleanup
DROP TABLE t1;

10.2 ASAN 7c5519c1

==1878099==ERROR: AddressSanitizer: global-buffer-overflow on address 0x56461fc1f234 at pc 0x7ff1aa8b4d00 bp 0x7ff19f984cb0 sp 0x7ff19f984458
READ of size 65 at 0x56461fc1f234 thread T5
    #0 0x7ff1aa8b4cff  (/lib/x86_64-linux-gnu/libasan.so.5+0xdacff)
    #1 0x56461dd29953 in get_constant_key_infix /data/src/10.2/sql/opt_range.cc:13305
    #2 0x56461dd25760 in get_best_group_min_max /data/src/10.2/sql/opt_range.cc:12741
    #3 0x56461dce2bdf in SQL_SELECT::test_quick_select(THD*, Bitmap<64u>, unsigned long long, unsigned long long, bool, bool, bool) /data/src/10.2/sql/opt_range.cc:2564
    #4 0x56461d41f4aa in get_quick_record_count /data/src/10.2/sql/sql_select.cc:3870
    #5 0x56461d42530f in make_join_statistics /data/src/10.2/sql/sql_select.cc:4491
    #6 0x56461d408374 in JOIN::optimize_inner() /data/src/10.2/sql/sql_select.cc:1584
    #7 0x56461d40369b in JOIN::optimize() /data/src/10.2/sql/sql_select.cc:1114
    #8 0x56461d41ecb1 in mysql_select(THD*, TABLE_LIST*, unsigned int, List<Item>&, Item*, unsigned int, st_order*, st_order*, Item*, st_order*, unsigned long long, select_result*, st_select_lex_unit*, st_select_lex*) /data/src/10.2/sql/sql_select.cc:3819
    #9 0x56461d3fbaa1 in handle_select(THD*, LEX*, select_result*, unsigned long) /data/src/10.2/sql/sql_select.cc:361
    #10 0x56461d373caf in execute_sqlcom_select /data/src/10.2/sql/sql_parse.cc:6218
    #11 0x56461d360ab7 in mysql_execute_command(THD*) /data/src/10.2/sql/sql_parse.cc:3524
    #12 0x56461d37d165 in mysql_parse(THD*, char*, unsigned int, Parser_state*, bool, bool) /data/src/10.2/sql/sql_parse.cc:7733
    #13 0x56461d356460 in dispatch_command(enum_server_command, THD*, char*, unsigned int, bool, bool) /data/src/10.2/sql/sql_parse.cc:1823
    #14 0x56461d35323c in do_command(THD*) /data/src/10.2/sql/sql_parse.cc:1377
    #15 0x56461d6d6e99 in do_handle_one_connection(CONNECT*) /data/src/10.2/sql/sql_connect.cc:1336
    #16 0x56461d6d675c in handle_one_connection /data/src/10.2/sql/sql_connect.cc:1241
    #17 0x56461ea56b3b in pfs_spawn_thread /data/src/10.2/storage/perfschema/pfs.cc:1869
    #18 0x7ff1aa6e9608 in start_thread /build/glibc-YYA7BZ/glibc-2.31/nptl/pthread_create.c:477
    #19 0x7ff1aa2c5102 in __clone (/lib/x86_64-linux-gnu/libc.so.6+0x122102)
 
0x56461fc1f234 is located 0 bytes to the right of global variable 'is_null_string' defined in '/data/src/10.2/sql/opt_range.cc:139:14' (0x56461fc1f220) of size 20
SUMMARY: AddressSanitizer: global-buffer-overflow (/lib/x86_64-linux-gnu/libasan.so.5+0xdacff) 
Shadow bytes around the buggy address:
  0x0ac943f7bdf0: f9 f9 f9 f9 f9 f9 f9 f9 f9 f9 f9 f9 f9 f9 f9 f9
  0x0ac943f7be00: f9 f9 f9 f9 f9 f9 f9 f9 f9 f9 f9 f9 f9 f9 f9 f9
  0x0ac943f7be10: f9 f9 f9 f9 f9 f9 f9 f9 f9 f9 f9 f9 f9 f9 f9 f9
  0x0ac943f7be20: f9 f9 f9 f9 f9 f9 f9 f9 f9 f9 f9 f9 f9 f9 f9 f9
  0x0ac943f7be30: f9 f9 f9 f9 f9 f9 f9 f9 f9 f9 f9 f9 f9 f9 f9 f9
=>0x0ac943f7be40: f9 f9 f9 f9 00 00[04]f9 f9 f9 f9 f9 00 00 00 00
  0x0ac943f7be50: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x0ac943f7be60: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x0ac943f7be70: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x0ac943f7be80: 00 00 00 00 f9 f9 f9 f9 f9 f9 f9 f9 f9 f9 f9 f9
  0x0ac943f7be90: f9 f9 f9 f9 f9 f9 f9 f9 f9 f9 f9 f9 f9 f9 f9 f9
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
  Shadow gap:              cc
Thread T5 created by T0 here:
    #0 0x7ff1aa814805 in pthread_create (/lib/x86_64-linux-gnu/libasan.so.5+0x3a805)
    #1 0x56461ea56f2c in spawn_thread_v1 /data/src/10.2/storage/perfschema/pfs.cc:1919
    #2 0x56461d0fb177 in inline_mysql_thread_create /data/src/10.2/include/mysql/psi/mysql_thread.h:1246
    #3 0x56461d112b07 in create_thread_to_handle_connection(CONNECT*) /data/src/10.2/sql/mysqld.cc:6518
    #4 0x56461d113298 in create_new_thread /data/src/10.2/sql/mysqld.cc:6588
    #5 0x56461d114423 in handle_connections_sockets() /data/src/10.2/sql/mysqld.cc:6846
    #6 0x56461d111e79 in mysqld_main(int, char**) /data/src/10.2/sql/mysqld.cc:6137
    #7 0x56461d0f9a5c in main /data/src/10.2/sql/main.cc:25
    #8 0x7ff1aa1ca0b2 in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x270b2)
 
==1878099==ABORTING

Reproducible on 10.1-10.5 with at least InnoDB, MyISAM, Aria.
No obvious effect on a non-ASAN build.

ANALYZE (from a non-ASAN build of the same revision, assuming the plans are the same):

ANALYZE
{
  "query_block": {
    "select_id": 1,
    "r_loops": 1,
    "r_total_time_ms": 0.0307,
    "table": {
      "table_name": "t1",
      "access_type": "index",
      "key": "a",
      "key_length": "70",
      "used_key_parts": ["a", "b"],
      "r_loops": 1,
      "rows": 2,
      "r_rows": 2,
      "r_total_time_ms": 0.0141,
      "filtered": 100,
      "r_filtered": 50,
      "attached_condition": "t1.b is null or t1.b < 'baz'",
      "using_index": true
    }
  }
}


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