[Bug sanitizer/108541] New: ASAN since GCC 9 missed a stack-buffer-overflow

[Bug sanitizer/108541] New: ASAN since GCC 9 missed a stack-buffer-overflow

[shaohua.li at inf dot ethz.ch]

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

            Bug ID: 108541
           Summary: ASAN since GCC 9 missed 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, ASAN at -O0 missed the stack-buffer-overflow while
other opt levels caught it. This issue happens since GCC-9. GCC-8 and before
worked fine.

I also noticed that there is an incompatible pointer assignment `i = &m`, but
anyway the bufferoverflow should be reported.

Clang can detect it at all opt levels.

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

% cat a.c
struct a {
  long b;
  int c;
  long d;
  short e;
  long f;
  long g;
};
struct {
  struct a b;
  unsigned : 6;
} h, *i;
int j;
int main() {
  struct a *k;
  &k;
  long l[3];
  l[j] = 4;
  int m = 1;
  i = &m;
  *i = h;
  return m;
}
% 
% gcc-tk -fsanitize=address -w -O0 a.c && ./a.out
% 
% gcc-tk -fsanitize=address -w -O1 a.c && ./a.out
=================================================================
==1==ERROR: AddressSanitizer: stack-buffer-overflow on address 0x7f8605800030
at pc 0x0000004012e0 bp 0x7ffdfd9e9b10 sp 0x7ffdfd9e9b08
WRITE of size 56 at 0x7f8605800030 thread T0
    #0 0x4012df in main /a.c:21
    #1 0x7f860810f082 in __libc_start_main
(/lib/x86_64-linux-gnu/libc.so.6+0x24082) (BuildId:
1878e6b475720c7c51969e69ab2d276fae6d1dee)
    #2 0x4010cd in _start (/a.s+0x4010cd) (BuildId:
62f9205a5d8cda9f9cd98eb2592c0ba25a6a0a20)

Address 0x7f8605800030 is located in stack of thread T0 at offset 48 in frame
    #0 0x401195 in main /app/example.c:14

  This frame has 2 object(s):
    [48, 52) 'm' (line 19) <== Memory access at offset 48 partially overflows
this variable
    [64, 88) 'l' (line 17) <== Memory access at offset 48 partially 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-overflow /a.c:21 in main
Shadow bytes around the buggy address:
...
%

[Bug sanitizer/108541] ASAN since GCC 9 missed a stack-buffer-overflow since r9-4503-g6e644a50045f8032

[marxin at gcc dot gnu.org]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Last reconfirmed|                            |2023-01-26
            Summary|ASAN since GCC 9 missed a   |ASAN since GCC 9 missed a
                   |stack-buffer-overflow       |stack-buffer-overflow since
                   |                            |r9-4503-g6e644a50045f8032
           Assignee|unassigned at gcc dot gnu.org      |marxin at gcc dot gnu.org
     Ever confirmed|0                           |1
             Status|UNCONFIRMED                 |ASSIGNED

--- Comment #1 from Martin Liška <marxin at gcc dot gnu.org> ---
Good catch! Started with my r9-4503-g6e644a50045f8032.

[Bug sanitizer/108541] ASAN since GCC 9 missed a stack-buffer-overflow since r9-4503-g6e644a50045f8032

[marxin at gcc dot gnu.org]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|ASSIGNED                    |RESOLVED
         Resolution|---                         |WONTFIX

--- Comment #2 from Martin Liška <marxin at gcc dot gnu.org> ---
Ok, I've got a reduced test-case:

cat pr108541.c
struct S {
  // WORKS: char padding[48];
  char padding[49];
};

struct S h, *i;

int main() {
  int *dummy;
  &dummy;

  int m = 1;
  char *ptr = (char *)&m;
  *(struct S *)(char *)(ptr - 0) = h;
  return 0;
}

so the shadow memory looks like this:
0x7ffff5300000: f1 f1 f1 f1 f1 f1 04 f2 00 f3 f3 f3

    [48, 52) 'm' (line 12)
    [64, 72) 'dummy' (line 9)

what happens here: during the expansion of   .ASAN_CHECK (5, ptr_5, 49, 1);


we check for the memory area beginning (that's fine), and than the ending,
which is out of the poisoned memory. It's unfortunate that the middle area of
the 49B contains a poisoned memory.
Closing as won't fix, we can't check every single byte of shadow memory, that
would be very slow.