[Bug sanitizer/105405] New: missed buffer-overflow in -O0

[Bug sanitizer/105405] New: missed buffer-overflow in -O0

[shaohua.li at inf dot ethz.ch]

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

            Bug ID: 105405
           Summary: missed buffer-overflow in -O0
           Product: gcc
           Version: 12.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 -fsanitize=address -O0` would miss the report,
while `gcc -fsanitize=address -O3` would not.

$cat a.c
main() {
  int a[1][1];
  {
    int *b[1];
  }
  a[1][3]++;
}
$
$gcc -fsanitize=address -w -O0 a.c ; ./a.out
$
$gcc -fsanitize=address -w -O3 a.c ; ./a.out
=================================================================
==6342==ERROR: AddressSanitizer: stack-buffer-overflow on address
0x7f8843a00030 at pc 0x0000004010f9 bp 0x7fff0b7f6a40 sp 0x7fff0b7f6a38
READ of size 4 at 0x7f8843a00030 thread T0
    #0 0x4010f8 in main
(/shared/mutate/array/trial_new/work0/debug40/a.out+0x4010f8)
    #1 0x7f8845c570b2 in __libc_start_main
(/lib/x86_64-linux-gnu/libc.so.6+0x240b2)
    #2 0x40117d in _start
(/shared/mutate/array/trial_new/work0/debug40/a.out+0x40117d)

Address 0x7f8843a00030 is located in stack of thread T0 at offset 48 in frame
    #0 0x40107f in main
(/shared/mutate/array/trial_new/work0/debug40/a.out+0x40107f)

  This frame has 1 object(s):
    [32, 36) 'a' (line 2) <== Memory access at offset 48 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
(/shared/mutate/array/trial_new/work0/debug40/a.out+0x4010f8) in main
Shadow bytes around the buggy address:
  0x0ff188737fb0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x0ff188737fc0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x0ff188737fd0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x0ff188737fe0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x0ff188737ff0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
=>0x0ff188738000: f1 f1 f1 f1 04 f3[f3]f3 00 00 00 00 00 00 00 00
  0x0ff188738010: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x0ff188738020: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x0ff188738030: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x0ff188738040: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x0ff188738050: 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
==6342==ABORTING

[Bug sanitizer/105405] missed buffer-overflow in -O0

[marxin at gcc dot gnu.org]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |WAITING
   Last reconfirmed|                            |2022-04-27
     Ever confirmed|0                           |1

--- Comment #1 from Martin Liška <marxin at gcc dot gnu.org> ---
Can you please try the fix that was applied for PR105396?

[Bug sanitizer/105405] missed buffer-overflow in -O0

[shaohua.li at inf dot ethz.ch]

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

--- Comment #2 from Li Shaohua <shaohua.li at inf dot ethz.ch> ---
Yeah, I've tried that fix. It didn't fix the issue though.

[Bug sanitizer/105405] missed buffer-overflow in -O0

[jakub at gcc dot gnu.org]

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

--- Comment #3 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
I think that is just misunderstanding on how ASan works and what it can
protect. It adds red zone around vars, so that access right after end of var or
before start of var is reported. But the red zone is quite small and needs to
be if we don't want to blow the whole stack, so if the overflow is farther away
and you are unlucky enough to reaching another var, it won't be diagnosed.
-fsanitize=undefined

[Bug sanitizer/105405] missed buffer-overflow in -O0

[shaohua.li at inf dot ethz.ch]

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

--- Comment #4 from Li Shaohua <shaohua.li at inf dot ethz.ch> ---
@Jakub, I agree with you that the above test case may access too far from the
red zone. However, for the below test case, I cannot figure out why -O0 again
did not report anything. As a user, I would think that *j[5][1]* did not reach
too far from the red zone although it might do according to your explanation.

$cat a.c
struct a {
  int b[9];
  long h
};
int i;
struct a j[6][1];
main() {
    if (j[5][1].h) {
        char k[4];
        k;
    }
}
$

[Bug sanitizer/105405] missed buffer-overflow in -O0

[jakub at gcc dot gnu.org]

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

Jakub Jelinek <jakub at gcc dot gnu.org> changed:

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

--- Comment #5 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
j[5][1].h is 36 after the end of a array, that is definitely too far.
Red zone can be 16 bytes or even less in certain cases (e.g. in the PR105396
case it is 12 bytes in between d and b variables).
ASan mostly protects against buffer overflows, something accesses the last byte
of a variable, then the byte after it, ... (or similarly the first byte of a
variable, then the byte before it, ...).
-fsanitize=undefined on the other side includes the bounds sanitizer that
verifies array indexes by comparing them against the number of elements the
array has.

[Bug sanitizer/105405] missed buffer-overflow in -O0

[marxin at gcc dot gnu.org]

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

--- Comment #6 from Martin Liška <marxin at gcc dot gnu.org> ---
(In reply to Jakub Jelinek from comment #5)
> j[5][1].h is 36 after the end of a array, that is definitely too far.

Yes. Just a small note that clang emits there a bit bigger red-zone:

=>0x0000801c50a0: 00 00 00 00 00 00 00 00 f9 f9 f9 f9 f9[f9]f9 f9
  0x0000801c50b0: 04 f9 f9 f9 00 00 00 00 00 00 00 00 00 00 00 00

and thus catches that.

> Red zone can be 16 bytes or even less in certain cases (e.g. in the PR105396
> case it is 12 bytes in between d and b variables).
> ASan mostly protects against buffer overflows, something accesses the last
> byte of a variable, then the byte after it, ... (or similarly the first byte
> of a variable, then the byte before it, ...).
> -fsanitize=undefined on the other side includes the bounds sanitizer that
> verifies array indexes by comparing them against the number of elements the
> array has.

gcc-11 pr105405.c -fsanitize=undefined && ./a.out
pr105405.c:10:13: runtime error: index 1 out of bounds for type 'a [1]'