From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <gcc-bugzilla@gcc.gnu.org>
Received: by sourceware.org (Postfix, from userid 48)
	id E0AD43858D20; Mon, 20 Feb 2023 20:57:10 +0000 (GMT)
DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org E0AD43858D20
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gcc.gnu.org;
	s=default; t=1676926630;
	bh=HzTrlQzDS7FAyaDUQjptOL3ynJCWu8BtV0v7IXYVLk8=;
	h=From:To:Subject:Date:From;
	b=EcyZahnKXrSXClwIVVKKkZmEZKKbV55LdtJ4xTC7SWt6Vm619pICUUO/NzZHCk4ao
	 XHpmS+3gajgE0VJyEMuW784TJJ/pbHgEu5m6uKMlyboGGfAXs4fbMwwc4uadLuDFzl
	 hSWs/ApFYILf1wS5hwwiGGNzaevofXbV5AZMhXo0=
From: "shaohua.li at inf dot ethz.ch" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug sanitizer/108864] New: Insufficient red zone in ASAN
Date: Mon, 20 Feb 2023 20:57:09 +0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: new
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: sanitizer
X-Bugzilla-Version: 13.0
X-Bugzilla-Keywords: 
X-Bugzilla-Severity: normal
X-Bugzilla-Who: shaohua.li at inf dot ethz.ch
X-Bugzilla-Status: UNCONFIRMED
X-Bugzilla-Resolution: 
X-Bugzilla-Priority: P3
X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org
X-Bugzilla-Target-Milestone: ---
X-Bugzilla-Flags: 
X-Bugzilla-Changed-Fields: bug_id short_desc product version bug_status
 bug_severity priority component assigned_to reporter cc target_milestone
Message-ID: <bug-108864-4@http.gcc.gnu.org/bugzilla/>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/
Auto-Submitted: auto-generated
MIME-Version: 1.0
List-Id: <gcc-bugs.sourceware.org>

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

            Bug ID: 108864
           Summary: Insufficient red zone in ASAN
           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, marxi=
n at gcc dot gnu.org
  Target Milestone: ---

For the following code, I found ASAN since GCC-9 would emit an insufficient
stack red zone for the variable `k`, which leads to a missed buffer-overflow
report. At -O0, there is no report from ASAN, but at -O1, the ASAN reported=
 a
stack-use-after-scope. After comparing with Clang's redzone allocation, I
believe that GCC's ASAN does not emit enough redzone for this case.

% cat a.c
struct a {
  long b;
};
struct c {
  int d;
} e[1];
int f;
static int *g() {
  struct c h;
  &h;
  f =3D 0;
  for (; f < 1; f++)
    ;
  return &e[0].d;
}
void i() {
  struct a j[1] =3D {};
  g();
  {
    struct c k=3D{1};
    int *l =3D &k.d;
    *(l + 4) =3D 0;
  }
  j;
}
int main() { i(); }
%
% gcc-tk -fsanitize=3Daddress -O0 a.c && ./a.out
%
% gcc-tk -fsanitize=3Daddress -O1 a.c && ./a.out
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
=3D=3D1=3D=3DERROR: AddressSanitizer: stack-use-after-scope on address 0x7f=
6f03700030
at pc 0x000000401291 bp 0x7ffd3ed6a410 sp 0x7ffd3ed6a408
WRITE of size 4 at 0x7f6f03700030 thread T0
    #0 0x401290 in i /app/example.c:22
    #1 0x4012c9 in main /app/example.c:26
    #2 0x7f6f0605c082 in __libc_start_main
(/lib/x86_64-linux-gnu/libc.so.6+0x24082) (BuildId:
1878e6b475720c7c51969e69ab2d276fae6d1dee)
    #3 0x4010cd in _start (/app/output.s+0x4010cd) (BuildId:
6d3e84a6ea228e86a3fc8319089c26dcbbcd8fb6)

Address 0x7f6f03700030 is located in stack of thread T0 at offset 48 in fra=
me
    #0 0x401195 in i /app/example.c:16

  This frame has 3 object(s):
    [32, 36) 'k' (line 20)
    [48, 52) 'h' (line 9) <=3D=3D Memory access at offset 48 is inside this
variable
    [64, 72) 'j' (line 17)
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-use-after-scope /app/example.c:22 in i
Shadow bytes around the buggy address:
  0x7f6f036ffd80: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x7f6f036ffe00: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x7f6f036ffe80: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x7f6f036fff00: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x7f6f036fff80: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
=3D>0x7f6f03700000: f1 f1 f1 f1 04 f2[f8]f2 00 f3 f3 f3 00 00 00 00
  0x7f6f03700080: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x7f6f03700100: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x7f6f03700180: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x7f6f03700200: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x7f6f03700280: 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):
...
%=