Bug 108864 - Insufficient red zone in ASAN
Summary: Insufficient red zone in ASAN
Status: RESOLVED INVALID
Alias: None
Product: gcc
Classification: Unclassified
Component: sanitizer (show other bugs)
Version: 13.0
: P3 normal
Target Milestone: ---
Assignee: Not yet assigned to anyone
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2023-02-20 20:57 UTC by Shaohua Li
Modified: 2023-02-20 21:05 UTC (History)
5 users (show)

See Also:
Host:
Target:
Build:
Known to work:
Known to fail:
Last reconfirmed:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Shaohua Li 2023-02-20 20:57:09 UTC
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 = 0;
  for (; f < 1; f++)
    ;
  return &e[0].d;
}
void i() {
  struct a j[1] = {};
  g();
  {
    struct c k={1};
    int *l = &k.d;
    *(l + 4) = 0;
  }
  j;
}
int main() { i(); }
%
% gcc-tk -fsanitize=address -O0 a.c && ./a.out
%
% gcc-tk -fsanitize=address -O1 a.c && ./a.out
=================================================================
==1==ERROR: AddressSanitizer: stack-use-after-scope on address 0x7f6f03700030 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 frame
    #0 0x401195 in i /app/example.c:16

  This frame has 3 object(s):
    [32, 36) 'k' (line 20)
    [48, 52) 'h' (line 9) <== 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
=>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):
...
%
Comment 1 Andrew Pinski 2023-02-20 21:05:19 UTC
><== Memory access at offset 48 is inside this variable

Basically GCC's red zone is up to 16 bytes. 
See PR 105405 also.