[Bug sanitizer/106368] New: ASan fails to report an error.

[Bug sanitizer/106368] New: ASan fails to report an error.

[shaohua.li at inf dot ethz.ch]

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

            Bug ID: 106368
           Summary: ASan fails to report an error.
           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: ---

Hi,

For the following code snippet, `gcc-trunk -O0 -fsanitize=address` reports
nothing but `gcc-trunk -O3` reports it.

$ cat a.c
#pragma pack(1)
struct a {
  int b;
  long c
};
#pragma pack()
struct d {
  long b;
  struct a c
};
struct d f;
static long *g = &f.c.c;
int main() {
    volatile int e = *(g+1);
}
$
$gcc-trunk -O0 -fsanitize=address a.c && ./a.out
$
$gcc-trunk -O3 -fsanitize=address a.c && ./a.out
================================================================
==1==ERROR: AddressSanitizer: unknown-crash on address 0x000000404134 at pc
0x0000004011a8 bp 0x7ffeadf39d20 sp 0x7ffeadf39d18
READ of size 8 at 0x000000404134 thread T0
    #0 0x4011a7 in main /app/example.c:14
    #1 0x7f044e5530b2 in __libc_start_main
(/lib/x86_64-linux-gnu/libc.so.6+0x240b2) (BuildId:
9fdb74e7b217d06c93172a8243f8547f947ee6d1)
    #2 0x40120d in _start (/app/output.s+0x40120d) (BuildId:
a4a82ec9bae1cc563083aff345004ea80e8df0db)

0x000000404138 is located 0 bytes to the right of global variable 'f' defined
in '/app/example.c:11:10' (0x404120) of size 24
SUMMARY: AddressSanitizer: unknown-crash /app/example.c:14 in main
Shadow bytes around the buggy address:
  0x0000800787d0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x0000800787e0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x0000800787f0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x000080078800: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x000080078810: 00 00 00 00 f9 f9 f9 f9 f9 f9 f9 f9 00 00 00 00
=>0x000080078820: 00 00 00 00 00 00[00]f9 f9 f9 f9 f9 00 00 00 00
  0x000080078830: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x000080078840: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x000080078850: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x000080078860: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x000080078870: 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
==1==ABORTING

[Bug sanitizer/106368] ASan fails to report an error.

[marxin at gcc dot gnu.org]

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

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> ---
ASAN can't detect that because of the following addresses and sizes:

gcc pr106368.c && ./a.out
&f=0x404030
g+1=0x404044
sizeof(f)=24

Thus g + 1 seems fine to ASAN. On the other hand *(g+2) does:

=================================================================
==18451==ERROR: AddressSanitizer: global-buffer-overflow on address
0x00000040421c at pc 0x000000401274 bp 0x7fffffffdab0 sp 0x7fffffffdaa8
READ of size 8 at 0x00000040421c thread T0
    #0 0x401273 in main (/home/marxin/Programming/testcases/a.out+0x401273)
    #1 0x7ffff74405af in __libc_start_call_main
../sysdeps/nptl/libc_start_call_main.h:58
    #2 0x7ffff7440678 in __libc_start_main_impl ../csu/libc-start.c:392
    #3 0x4010c4 in _start (/home/marxin/Programming/testcases/a.out+0x4010c4)

0x00000040421c is located 4 bytes to the right of global variable 'f' defined
in 'pr106368.c:11:10' (0x404200) of size 24
SUMMARY: AddressSanitizer: global-buffer-overflow
(/home/marxin/Programming/testcases/a.out+0x401273) in main
Shadow bytes around the buggy address:
  0x0000800787f0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x000080078800: 00 00 00 00 00 f9 f9 f9 f9 f9 f9 f9 00 00 00 00
  0x000080078810: f9 f9 f9 f9 f9 f9 f9 f9 f9 f9 f9 f9 f9 f9 f9 f9
  0x000080078820: f9 f9 f9 f9 f9 f9 f9 f9 f9 f9 f9 f9 f9 f9 f9 f9
  0x000080078830: f9 f9 f9 f9 f9 f9 f9 f9 00 00 00 00 00 00 00 00
=>0x000080078840: 00 00 00[f9]f9 f9 f9 f9 00 00 00 00 00 00 00 00

Btw. UBSAN detects the misaligned address for *(g+1):

pr106368.c:17:22: runtime error: load of misaligned address 0x000000404154 for
type 'long int', which requires 8 byte alignment
0x000000404154: note: pointer points here
  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  00
00 00 00 00 00 00 00

Note clang also can't detect that. Thus I tend to close it as invalid.