[MXS-4567] test_users fails on SLES 15 when run with ASAN Created: 2023-03-28  Updated: 2024-02-03  Resolved: 2023-03-29

Status: Closed
Project: MariaDB MaxScale
Component/s: test
Affects Version/s: 2.5.24
Fix Version/s: N/A

Type: Bug Priority: Major
Reporter: markus makela Assignee: markus makela
Resolution: Not a Bug Votes: 0
Labels: None
Environment:

SLES 15 SP4



 Description   

The test fails with the following:

=================================================================
==3450==ERROR: AddressSanitizer: stack-buffer-overflow on address 0x7ffd5ccab3d0 at pc 0x7f01f27b1a96 bp 0x7ffd5cca3360 sp 0x7ffd5cca2b10
WRITE of size 131232 at 0x7ffd5ccab3d0 thread T0
    #0 0x7f01f27b1a95  (/usr/lib64/libasan.so.6+0x53a95)
    #1 0x7f01f219f5bc in maxscale::crypt(std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&, std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&) /home/timofey_turenko_mariadb_com/MaxScale/server/core/utils.cc:729
    #2 0x7f01f2194294 in maxscale::Users::hash(std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&) /home/timofey_turenko_mariadb_com/MaxScale/server/core/users.cc:270
    #3 0x7f01f21918a4 in maxscale::Users::add(std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&, std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&, maxscale::user_account_type) /home/timofey_turenko_mariadb_com/MaxScale/server/core/users.cc:75
    #4 0x7f01f1da0697 in admin_add_user /home/timofey_turenko_mariadb_com/MaxScale/server/core/adminusers.cc:136
    #5 0x7f01f1da230b in admin_add_inet_user(char const*, char const*, maxscale::user_account_type) /home/timofey_turenko_mariadb_com/MaxScale/server/core/adminusers.cc:372
    #6 0x7f01f1d9fab9 in rest_users_init() /home/timofey_turenko_mariadb_com/MaxScale/server/core/adminusers.cc:75
    #7 0x401392 in main /home/timofey_turenko_mariadb_com/MaxScale/server/core/test/test_adminusers.cc:83
    #8 0x7f01ef32129c in __libc_start_main (/lib64/libc.so.6+0x3529c)
    #9 0x401059 in _start (/home/timofey_turenko_mariadb_com/MaxScale/_build/server/core/test/test_adminusers+0x401059)
Address 0x7ffd5ccab3d0 is located in stack of thread T0 at offset 32832 in frame
    #0 0x7f01f219f449 in maxscale::crypt(std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&, std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&) /home/timofey_turenko_mariadb_com/MaxScale/server/core/utils.cc:725
  This frame has 2 object(s):
    [48, 49) '<unknown>'
    [64, 32832) 'cdata' (line 727) <== Memory access at offset 32832 overflows this variable
HINT: this may be a false positive if your program uses some custom stack unwind mechanism, swapcontext or vfork
      (longjmp and C++ exceptions *are* supported)
SUMMARY: AddressSanitizer: stack-buffer-overflow (/usr/lib64/libasan.so.6+0x53a95) 
Shadow bytes around the buggy address:
  0x10002b98d620: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x10002b98d630: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x10002b98d640: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x10002b98d650: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x10002b98d660: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
=>0x10002b98d670: 00 00 00 00 00 00 00 00 00 00[f3]f3 f3 f3 f3 f3
  0x10002b98d680: f3 f3 f3 f3 f3 f3 f3 f3 f3 f3 f3 f3 f3 f3 f3 f3
  0x10002b98d690: f3 f3 f3 f3 f3 f3 f3 f3 f3 f3 00 00 00 00 00 00
  0x10002b98d6a0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 f1 f1
  0x10002b98d6b0: f1 f1 f1 f1 01 f2 00 f2 f2 f2 f8 f2 f2 f2 00 00
  0x10002b98d6c0: 00 f2 f2 f2 f2 f2 00 00 00 00 f2 f2 f2 f2 00 00
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
==3450==ABORTING

This seems suspicious and it warrants extra investigation to figure out if it's a problem in SLES or somewhere in MaxScale.



 Comments   
Comment by markus makela [ 2023-03-29 ]

This looks like a problem that's only on SLES 15 SP4. The problem goes away if a large enough buffer is used to store the struct crypt_data. This suggests that there's some incompatibility with the size of struct crypt_data that's being used by the test and the one that ASAN uses.

Here's a minimal test program that demonstrates the problem:

#include <crypt.h>
#include <iostream>
#include <cstring>
 
int main(int argc, char** argv)
{
  struct crypt_data data;
  memset(&data, 0, sizeof(data));
  std::cout << crypt_r(argv[1], argv[2], &data) << std::endl;
  return 0;
}

Valgrind detects no errors which suggests it is indeed a problem in the ASAN implementation.

Comment by markus makela [ 2024-02-03 ]

Filed a bug for this in SLES: https://bugzilla.opensuse.org/show_bug.cgi?id=1219520

Generated at Thu Feb 08 04:29:34 UTC 2024 using Jira 8.20.16#820016-sha1:9d11dbea5f4be3d4cc21f03a88dd11d8c8687422.