[Bug sanitizer/107696] New: GCC trunk misses a stack-buffer-overflow

[Bug sanitizer/107696] New: GCC trunk misses a stack-buffer-overflow

[shaohua.li at inf dot ethz.ch]

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

            Bug ID: 107696
           Summary: GCC trunk misses a stack-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, `gcc-trunk -O0 -fsanitize=address` misses the
stack-buffer-overflow, while `gcc-trunk -Ox -fsanitize=address` (x=1,2,3, or s)
can detect it. 

clang can detect it at all optimization levels.

gcc-8 can detect it at all optimization levels.

Compiler explorer: https://godbolt.org/z/z18Kzhxq5

% cat a.c
int main() {
    int i;
    int a[1];
    for (; i < 1;){ 
        i = 2;
        a[i] = 1;
    }
    __builtin_printf("%d\n", a[i]);
}
%
% gcc-tk -O0 -fsanitize=address a.c &&./a.out
0
% gcc-tk -O3 -fsanitize=address a.c &&./a.out
=================================================================
==1940238==ERROR: AddressSanitizer: stack-buffer-overflow on address
0x7f9590400028 at pc 0x000000401147 bp 0x7fff56ba4240 sp 0x7fff56ba4238
READ of size 4 at 0x7f9590400028 thread T0
    #0 0x401146 in main
/zdata/shaoli/sanitizertesting/mutate/synthesizer/bugs/gcc_work1_0/a.c:8
    #1 0x7f9592de7082 in __libc_start_main
(/lib/x86_64-linux-gnu/libc.so.6+0x24082) (BuildId:
1878e6b475720c7c51969e69ab2d276fae6d1dee)
    #2 0x4011dd in _start
(/zdata/shaoli/sanitizertesting/mutate/synthesizer/bugs/gcc_work1_0/a.out+0x4011dd)

Address 0x7f9590400028 is located in stack of thread T0 at offset 40 in frame
    #0 0x4010bf in main
/zdata/shaoli/sanitizertesting/mutate/synthesizer/bugs/gcc_work1_0/a.c:1

  This frame has 1 object(s):
    [32, 36) 'a' (line 3) <== Memory access at offset 40 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
/zdata/shaoli/sanitizertesting/mutate/synthesizer/bugs/gcc_work1_0/a.c:8 in
main
Shadow bytes around the buggy address:
  0x0ff332077fb0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x0ff332077fc0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x0ff332077fd0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x0ff332077fe0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x0ff332077ff0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
=>0x0ff332078000: f1 f1 f1 f1 04[f3]f3 f3 00 00 00 00 00 00 00 00
  0x0ff332078010: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x0ff332078020: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x0ff332078030: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x0ff332078040: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x0ff332078050: 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
==1940238==ABORTING
%
% gcc-tk -v
Using built-in specs.
COLLECT_GCC=gcc-tk
COLLECT_LTO_WRAPPER=/zdata/shaoli/compilers/ccbuilder-compilers/gcc-7ca912b46e0eb45ebefeb0eda4c28afe1513d272/libexec/gcc/x86_64-pc-linux-gnu/13.0.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: ../configure --disable-multilib --disable-bootstrap
--enable-languages=c,c++
--prefix=/zdata/shaoli/compilers/ccbuilder-compilers/gcc-7ca912b46e0eb45ebefeb0eda4c28afe1513d272
Thread model: posix
Supported LTO compression algorithms: zlib
gcc version 13.0.0 20221108 (experimental) (GCC)
%

[Bug sanitizer/107696] GCC trunk misses a stack-buffer-overflow

[marxin at gcc dot gnu.org]

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

Martin Liška <marxin at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |RESOLVED
         Resolution|---                         |INVALID

--- Comment #1 from Martin Liška <marxin at gcc dot gnu.org> ---
>     int i;
>     int a[1];
>     for (; i < 1;){ 

This depends on the uninitialized value of 'i', which is:

(gdb) p i
$1 = 32767

if I run it with -O0 on my local machine. You can try
-ftrivial-auto-var-init=zero.

[Bug sanitizer/107696] GCC trunk misses a stack-buffer-overflow

[shaohua.li at inf dot ethz.ch]

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

--- Comment #2 from Li Shaohua <shaohua.li at inf dot ethz.ch> ---
(In reply to Martin Liška from comment #1)
> >     int i;
> >     int a[1];
> >     for (; i < 1;){ 
> 
> This depends on the uninitialized value of 'i', which is:
> 
> (gdb) p i
> $1 = 32767
> 
> if I run it with -O0 on my local machine. You can try
> -ftrivial-auto-var-init=zero.

Sorry, I over-reduced the test, for the following new test, I can still observe
the inconsistent results across optimization levels:

Compiler explorer: https://godbolt.org/z/b7x9zx5Ej
% cat a.c
int main() {
    int b[2];
    int a[1];
    int i;
    for (i=0; i < 1; i++) 
        i = i + 3;
    a[i] = 1;
}
%

[Bug sanitizer/107696] GCC trunk misses a stack-buffer-overflow

[marxin at gcc dot gnu.org]

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

--- Comment #3 from Martin Liška <marxin at gcc dot gnu.org> ---
So here again depends on the order of stack variables and a[4] is a valid
access to 'b' variable, see what happens with a[6]:

=================================================================
==6539==ERROR: AddressSanitizer: stack-buffer-overflow on address
0x7fffffffd5f8 at pc 0x000000401291 bp 0x7fffffffd590 sp 0x7fffffffd588
WRITE of size 4 at 0x7fffffffd5f8 thread T0
    #0 0x401290 in main (/home/marxin/Programming/testcases/a.out+0x401290)
    #1 0x7ffff762c5af in __libc_start_call_main (/lib64/libc.so.6+0x275af)
    #2 0x7ffff762c678 in __libc_start_main_impl (/lib64/libc.so.6+0x27678)
    #3 0x4010c4 in _start ../sysdeps/x86_64/start.S:115

Address 0x7fffffffd5f8 is located in stack of thread T0 at offset 72 in frame
    #0 0x4011a5 in main (/home/marxin/Programming/testcases/a.out+0x4011a5)

  This frame has 2 object(s):
    [48, 52) 'a' (line 3)
    [64, 72) 'b' (line 2) <== Memory access at offset 72 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
(/home/marxin/Programming/testcases/a.out+0x401290) in main
Shadow bytes around the buggy address:
  0x10007fff7a60: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x10007fff7a70: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x10007fff7a80: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x10007fff7a90: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x10007fff7aa0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
=>0x10007fff7ab0: 00 00 00 00 00 00 f1 f1 f1 f1 f1 f1 04 f2 00[f3]
  0x10007fff7ac0: f3 f3 00 00 00 00 00 00 00 00 00 00 00 00 00 00

[Bug sanitizer/107696] GCC trunk misses a stack-buffer-overflow

[shaohua.li at inf dot ethz.ch]

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

--- Comment #4 from Li Shaohua <shaohua.li at inf dot ethz.ch> ---
Thanks for the prompt reply.