[Bug sanitizer/108903] New: ASAN may miss a global-buffer-overflow

["shaohua.li at inf dot ethz.ch" <gcc-bugzilla@gcc.gnu.org>]

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

            Bug ID: 108903
           Summary: ASAN may miss a global-buffer-overflow
           Product: gcc
           Version: 13.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: sanitizer
          Assignee: unassigned at gcc dot gnu.org
          Reporter: shaohua.li at inf dot ethz.ch
                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, marxin at gcc dot gnu.org
  Target Milestone: ---

For the following code, ASAN at -Os did not report the global-buffer-overflow
while other opt levels did. 

$ cat a.c
int a, e, c;
short b;
static int *d = &e;
int main() {
  for (; b < 4; b++) {
    int *f = &a;
    for (; c <= 7; c++) {
      *f = *(d + 1);
      if (*d)
        break;
      *f = 0;
    }
    a=*f;
  }
  return a;
}
$
$ gcc a.c -fsanitize=address -Os && ./a.out
$
$ gcc a.c -fsanitize=address -O3 && ./a.out
=================================================================
==1==ERROR: AddressSanitizer: global-buffer-overflow on address 0x000000404244
at pc 0x00000040119a bp 0x7fff990d2e40 sp 0x7fff990d2e38
READ of size 4 at 0x000000404244 thread T0
    #0 0x401199 in main /app/a.c:8
    #1 0x7fc4eaa09082 in __libc_start_main
(/lib/x86_64-linux-gnu/libc.so.6+0x24082) (BuildId:
1878e6b475720c7c51969e69ab2d276fae6d1dee)
    #2 0x4011fd in _start (/app/a.s+0x4011fd) (BuildId:
ffda4adec8a32a35ec5ae846f253cc2fcc431a06)
...
$


I realize that the statement `*f = *(d + 1)` may have been optimized out and it
is indeed according to the optimized tree:

$ gcc-tk a.c -Os -fsanitize=address -fdump-tree-optimized=/dev/stdout
...
bb 3> [local count: 1014686024]:
  ivtmp.23_58 = ivtmp.23_34 + 1;
  if (_3 != 0)
    goto <bb 4>; [5.50%]
  else
    goto <bb 7>; [94.50%]

  <bb 4> [local count: 55807731]:
  _49 = (unsigned long) &MEM[(int *)&e + 4B];
  _43 = _49 >> 3;
  _10 = _43 + 2147450880;
..
$

So the ASAN checking branch won't be executed. However, when I check the
generated ASM, I find that the `e+4` has been used. I wonder if some later
passes promote the overflowed instructions from a dead part. If yes, this is
potentially very dangerous.

$ gcc-tk a.c -Os -fsanitize=address -S -o /dev/stdout
...
main:
        movl    $e+4, %edx         <-- e+4 is used
        movw    b(%rip), %ax
        pushq   %rbx
        xorl    %ecx, %ecx
        movq    %rdx, %rbx
        movl    e(%rip), %r11d
...