[Bug sanitizer/113482] New: Sanitizer configuration error

[Bug sanitizer/113482] New: Sanitizer configuration error

[jiajing_zheng at 163 dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113482

            Bug ID: 113482
           Summary: Sanitizer configuration error
           Product: gcc
           Version: 12.2.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: sanitizer
          Assignee: unassigned at gcc dot gnu.org
          Reporter: jiajing_zheng at 163 dot com
                CC: dodji at gcc dot gnu.org, dvyukov at gcc dot gnu.org,
                    jakub at gcc dot gnu.org, kcc at gcc dot gnu.org
  Target Milestone: ---

elowen@elowen-MS-7C82:~$ cat test.i
# 0 "test.c"
# 0 "<built-in>"
# 0 "<command-line>"
# 1 "/usr/include/stdc-predef.h" 1 3 4
# 0 "<command-line>" 2
# 1 "test.c"

static int g_a6[46];
static unsigned int g_b6[46];

static unsigned short g_17 = 1U;
static int g_58 = 8;
static int *g_145 = (void *)0;
static int **g_258 = &g_145;
static int **const g_373 = &g_145;
static const unsigned int g_391 = 0U;
static unsigned char g_912 = 0b11111000;


static void func_1(void);
static void func_2(int *p_4);
static void func_11(char p_14);

static void func_1(void) {
  func_11(g_17);
  func_2(&g_58);
}

static void func_2(int *p_4) {
  int *l_247 = &g_58;
  int **const l_256 = &l_247;
  int ii_0;
  int jj_0;
  int ij_0;

  for (g_17 = (-25), ii_0 = 0, jj_0 = 0, ij_0 = 0; ij_0 <= 46; ij_0++) {
    if (ij_0 <= 25 && (g_17 > 42)) {
      g_a6[ii_0] = g_912 * (*p_4) - (**g_373);
      g_17++;
      ii_0++;
    }
    if (ij_0 <= 46 && jj_0 < 46) {
      g_b6[jj_0] = g_391 * g_a6[jj_0] - g_912;
      jj_0++;
    }
  }
  (*g_258) = p_4;
  if ((p_4 != (*g_373))) {
    if (((*p_4) > *g_145) == g_17) {
      func_11(g_58);
    }
  }
}

static void func_11(char p_14) {
  int *l_57 = &g_58;
  int l_92 = 0;
  int **l_177 = &g_145;
  int **l_86 = &l_57;
  (*l_177) = &l_92;
  if (((unsigned short)p_14 - (unsigned short)((*l_57) % g_58)) != g_58) {
    (*g_145) = 0b11111001010100101000111011100111;
  }
}

int main(void) {
  func_1();
  return 0;
}

I used -fsanitize to check the test.i for undefined and address, and found that
when undefined and address were used separately, no error messages were given
at some optimization levels(-O0, -O1, -O2, -O3, -Os).

Here are the command lines:

gcc test.i -O<level> -w -fsanitize=undefined && ./a.out
gcc test.i -O<level> -w -fsanitize=address && ./a.out

But when undefined and address were used together, only error messages were
given at -O0. I think GCC's -fsanitize=undefined,address is problematic at the
-O0 level.

Here are the command lines and output results:

elowen@elowen-MS-7C82:~$ gcc test.i -w -fno-omit-frame-pointer -g
-fsanitize=undefined,address -O1 && ./a.out
elowen@elowen-MS-7C82:~$ gcc test.i -w -fno-omit-frame-pointer -g
-fsanitize=undefined,address -O2 && ./a.out
elowen@elowen-MS-7C82:~$ gcc test.i -w -fno-omit-frame-pointer -g
-fsanitize=undefined,address -O3 && ./a.out
elowen@elowen-MS-7C82:~$ gcc test.i -w -fno-omit-frame-pointer -g
-fsanitize=undefined,address -Os && ./a.out
elowen@elowen-MS-7C82:~$ gcc test.i -w -fno-omit-frame-pointer -g
-fsanitize=undefined,address -O0 && ./a.out
=================================================================
==292611==ERROR: AddressSanitizer: stack-buffer-underflow on address
0x7ffedfdc5320 at pc 0x000000401469 bp 0x7ffedfdc52c0 sp 0x7ffedfdc52b8
READ of size 4 at 0x7ffedfdc5320 thread T0
    #0 0x401468 in func_2 /home/elowen/test.c:32
    #1 0x401244 in func_1 /home/elowen/test.c:20
    #2 0x401d1a in main /home/elowen/test.c:61
    #3 0x7f78b1029d8f in __libc_start_call_main
../sysdeps/nptl/libc_start_call_main.h:58
    #4 0x7f78b1029e3f in __libc_start_main_impl ../csu/libc-start.c:392
    #5 0x401164 in _start (/home/elowen/a.out+0x401164)

Address 0x7ffedfdc5320 is located in stack of thread T0 at offset 16 in frame
    #0 0x401257 in func_2 /home/elowen/test.c:23

  This frame has 1 object(s):
    [32, 40) 'l_247' (line 24) <== Memory access at offset 16 underflows 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-underflow /home/elowen/test.c:32 in
func_2
Shadow bytes around the buggy address:
  0x10005bfb0a10: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x10005bfb0a20: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x10005bfb0a30: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x10005bfb0a40: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x10005bfb0a50: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
=>0x10005bfb0a60: 00 00 f1 f1[f1]f1 00 f3 f3 f3 00 00 00 00 00 00
  0x10005bfb0a70: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x10005bfb0a80: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x10005bfb0a90: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x10005bfb0aa0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x10005bfb0ab0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 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
==292611==ABORTING


Here is the GCC information:
elowen@elowen-MS-7C82:~$ gcc -v
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/home/elowen/gcc-install-12.2.0/usr/local/bin/../libexec/gcc/x86_64-pc-linux-gnu/12.2.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: ../configure -enable-checking=release -enable-languages=c,c++
-disable-multilib
Thread model: posix
Supported LTO compression algorithms: zlib
gcc version 12.2.0 (GCC)

[Bug sanitizer/113482] Sanitizer configuration error

[xry111 at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113482

Xi Ruoyao <xry111 at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |RESOLVED
         Resolution|---                         |INVALID
                 CC|                            |xry111 at gcc dot gnu.org

--- Comment #1 from Xi Ruoyao <xry111 at gcc dot gnu.org> ---
GCC 13.2 gives a better diagnostic, with -fsanitize=address -g:

==728119==ERROR: AddressSanitizer: stack-use-after-return on address
0x7f98b1709030 at pc 0x0000004013bd bp 0x7ffd9b8fcef0 sp 0x7ffd9b8fcee0
READ of size 4 at 0x7f98b1709030 thread T0
    #0 0x4013bc in func_2 /home/xry111/t.c:31
    #1 0x401227 in func_1 /home/xry111/t.c:19
    #2 0x40186b in main /home/xry111/t.c:60
    #3 0x7f98b4827f59 in __libc_start_call_main
../sysdeps/nptl/libc_start_call_main.h:58
    #4 0x7f98b4828024 in __libc_start_main_impl ../csu/libc-start.c:360
    #5 0x401100 in _start ../sysdeps/x86_64/start.S:115

Address 0x7f98b1709030 is located in stack of thread T0 at offset 48 in frame
    #0 0x401660 in func_11 /home/xry111/t.c:48

  This frame has 2 object(s):
    [48, 52) 'l_92' (line 50) <== Memory access at offset 48 is inside this
variable
    [64, 72) 'l_57' (line 49)
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-use-after-return /home/xry111/t.c:31 in func_2
Shadow bytes around the buggy address:
  0x7f98b1708d80: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x7f98b1708e00: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x7f98b1708e80: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x7f98b1708f00: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x7f98b1708f80: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
=>0x7f98b1709000: f5 f5 f5 f5 f5 f5[f5]f5 f5 f5 f5 f5 00 00 00 00
  0x7f98b1709080: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x7f98b1709100: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x7f98b1709180: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x7f98b1709200: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x7f98b1709280: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 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
==728119==ABORTING

Now it should be obvious that the code is buggy.  So with GCC 12
-fsanitize=undefined,address is at -O0 is correct, while the other combinations
produce a false negative.

You may argue the false negatives are also a bug but we don't backport the
fixes for sanitizer false negatives to old releases because doing so is
completely impractical (unless the fix is obvious and very simple).

[Bug sanitizer/113482] Sanitizer configuration error

[xry111 at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113482

--- Comment #2 from Xi Ruoyao <xry111 at gcc dot gnu.org> ---
Also note that the bug reporting guideline (https://gcc.gnu.org/bugs/) says "if
possible, try a current release or development snapshot."