https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108864
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, marxin 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 = 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): ... %