[Bug sanitizer/108343] New: ASAN at -O3 misses a heap-use-after-free
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108343
Bug ID: 108343
Summary: ASAN at -O3 misses a heap-use-after-free
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 -O3 misses the heap-use-after-free, while other
opt levels catch it.
% cat a.c
#include
int a, c;
char b;
int main() {
char **d = malloc(sizeof(char*));
for(int i=0; i<1; i++)
*d = malloc(sizeof(char));
d[0][0] = 0;
int e, f = -1;
free(d[0]);
free(d);
for (; a <= 1; a++) {
long g[1];
g;
c = f;
e = 0;
for (; e <= 1; e++) {
c |= d[a][0];
if (b)
c = a;
}
}
return c;
}
%
% gcc-tk -fsanitize=address -g -O2 a.c && ./a.out
=
==2253130==ERROR: AddressSanitizer: heap-use-after-free on address
0x60200010 at pc 0x00401210 bp 0x7ffdd10f9a90 sp 0x7ffdd10f9a88
READ of size 8 at 0x60200010 thread T0
#0 0x40120f in main /zdata/shaoli/sanitizertesting/mutate/bugs/gcc/a.c:18
#1 0x7f15496b0082 in __libc_start_main
(/lib/x86_64-linux-gnu/libc.so.6+0x24082) (BuildId:
1878e6b475720c7c51969e69ab2d276fae6d1dee)
...
%
% gcc-tk -fsanitize=address -g -O3 a.c && ./a.out
%
[Bug sanitizer/108481] New: UBsan missed a signed integer overflow
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108481
Bug ID: 108481
Summary: UBsan missed a signed integer 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, UBsan at -O1 and above missed the signed integer
overflow, while -O0 found it. I checked the assembly and the buggy code was not
optimized away.
Clang detected it at all optimization levels.
Compiler explorer: https://godbolt.org/z/rK6sad1WG
%cat a.c
int a, d;
short b;
short *c = &b;
int *const e = &d;
static char f(int *g, short h, long i) {
d = 2;
for (;; d--) {
int j = *e;
*g = (0 || h) / h;
*c = 3;
if ((i * (unsigned long)7 <= 1) << j)
;
else {
i = i - 6822162149299574294;
if (j) {
if (*g)
break;
continue;
}
return 8;
}
}
return h;
}
int main() {
int *k = &a;
f(k, 4, 8289379813243698614);
}
%
%gcc-tk -fsanitize=undefined -O1 && ./a.out
%
%gcc-tk -fsanitize=undefined -O0 && ./a.out
/a.c:14:9: runtime error: signed integer overflow: -5354944485355449974 -
6822162149299574294 cannot be represented in type 'long int'
%
[Bug sanitizer/108497] New: UBsan at -O1 failed to report an integer-overflow
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108497
Bug ID: 108497
Summary: UBsan at -O1 failed to report an integer-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, UBsan `-fsanitize=undefined -fno-sanitize-recover=all
-O1` failed to report the integer-overflow, while other opt levels reported it.
Interestingly, if you don't specify `-fno-sanitize-recover=all`, UBSAN can
report it normally.
Clang at all opt levels can detect it.
Compiler explorer: https://godbolt.org/z/dE1sfcz5f
% cat a.c
int a, c;
long *b;
int main() {
int d = 0, e = 0;
for (; e < 2; e++)
f:
for (; a; a++)
d % *b;
d = d + 1228455618;
c ^= 0 == 0;
if (c) {
e = 0;
for (; e < 1; e++)
;
goto f;
}
}
%
% gcc-tk -O1 -fsanitize=undefined -fno-sanitize-recover=all a.c && ./a.out
%
% gcc-tk -O2 -fsanitize=undefined -fno-sanitize-recover=all a.c && ./a.out
/a.c:9:5: runtime error: signed integer overflow: 1228455618 + 1228455618
cannot be represented in type 'int'
%
[Bug sanitizer/108510] New: ASAN missed a stack-use-after-scope at -O1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108510
Bug ID: 108510
Summary: ASAN missed a stack-use-after-scope at -O1
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, GCC's ASAN at -O1 missed the stack-use-after-scope,
while other opt levels detected it.
I checked the assembly code, -O1 didn't optimize away the buggy code.
Compiler explorer: https://godbolt.org/z/jWPG8hMWY
% cat a.c
short a;
char b;
short *c = &a, *d;
long e;
int main() {
long *f = &e;
{
int g=0;
d = &g;
}
*d << (b = ((*f)--, c || *d));
}
%
% gcc-tk -fsanitize=address -g -O1 a.c && ./a.out
%
% gcc-tk -fsanitize=address -g -O2 a.c && ./a.out
=
==1==ERROR: AddressSanitizer: stack-use-after-scope on address 0x7f0150b00020
at pc 0x004011a4 bp 0x743bc150 sp 0x743bc148
READ of size 2 at 0x7f0150b00020 thread T0
#0 0x4011a3 in main /a.c:11
#1 0x7f01534e6082 in __libc_start_main
(/lib/x86_64-linux-gnu/libc.so.6+0x24082) (BuildId:
1878e6b475720c7c51969e69ab2d276fae6d1dee)
#2 0x40123d in _start (/app/output.s+0x40123d) (BuildId:
2f09fd97ce9e5ec29ed33980daf91dfdd4bb3ebc)
Address 0x7f0150b00020 is located in stack of thread T0 at offset 32 in frame
#0 0x4010bf in main /a.c:5
...
%
[Bug sanitizer/108514] New: ASAN at -O0 missed a stack-use-after-scope
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108514
Bug ID: 108514
Summary: ASAN at -O0 missed a stack-use-after-scope
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 and -Os missed the stack-use-after-scope,
while other opt levels caught it. This issue is really concerning as it appears
at -O0.
Compiler explorer: https://godbolt.org/z/bWGbq6Er9
% cat a.c
int a = 5;
char b, d;
short c, e;
int main() {
int *f = &a;
b = 0;
for (; b != 9; b = 9) {
int g=7;
f = &g;
}
e = (c = d, a) || *f;
return e;
}
%
% gcc-tk -fsanitize=address -g -O0 a.c && ./a.out
%
% gcc-tk -fsanitize=address -g -O1 a.c && ./a.out
=
==1==ERROR: AddressSanitizer: stack-use-after-scope on address 0x7f5faf900020
at pc 0x004011e6 bp 0x7ffc50f70450 sp 0x7ffc50f70448
READ of size 4 at 0x7f5faf900020 thread T0
#0 0x4011e5 in main /a.c:11
#1 0x7f5fb22da082 in __libc_start_main
(/lib/x86_64-linux-gnu/libc.so.6+0x24082) (BuildId:
1878e6b475720c7c51969e69ab2d276fae6d1dee)
#2 0x4010bd in _start (/app/output.s+0x4010bd) (BuildId:
99c4c90f86135af6a6c35d4ef1af9a5d7e48c1ed)
Address 0x7f5faf900020 is located in stack of thread T0 at offset 32 in frame
#0 0x401185 in main /a.c:4
This frame has 1 object(s):
[32, 36) 'g' (line 8) <== Memory access at offset 32 is inside 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-use-after-scope /a.c:11 in main
Shadow bytes around the buggy address:
...
%
[Bug sanitizer/108510] ASAN missed a stack-use-after-scope at -O1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108510
--- Comment #2 from Li Shaohua ---
Sure: (compiler explorer: https://godbolt.org/z/3qEavnan5)
% cat a.c
int a;
char b;
int *c = &a, *d;
long e;
int main() {
long *f = &e;
{
int g=0;
d = &g;
}
*d << (b = ((*f)--, c || *d));
}
%
[Bug sanitizer/108541] New: ASAN since GCC 9 missed a stack-buffer-overflow
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 0x004012e0 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/108481] [13 Regression] UBsan missed a signed integer overflow
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108481
--- Comment #4 from Li Shaohua ---
(In reply to Andrew Pinski from comment #2)
> i = i - 6822162149299574294;
>
> Is not being invoked on the executable code.
>
> If we look at look at the original code:
>
>
> if ((i * (unsigned long)7 <= 1) << j)
> ;
> else {
> i = i - 6822162149299574294;
> if (j) {
> if (*g)
> break;
> continue;
> }
> return 8;
> }
> ...
> return h;
>
> The only path where the undefined behavior even matters is inside the path
> that had continue in it. Which is where the subtraction is pushed to now.
>
> I don't know if we should declear this as a valid thing to do or not.
When I compiled the source code with `-O1 -fsanitize=undefined` and then used
gdb to check the execution trace of the binary, I indeed observed that `i = i -
6822162149299574294` was executed.
[Bug sanitizer/108628] New: ASAN at -O3 misses a stack-use-after-return
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108628
Bug ID: 108628
Summary: ASAN at -O3 misses a stack-use-after-return
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 -O3 missed the stack-use-after-return, while
other opt levels detected it.
Clang at all opt levels can detect it.
Compiler explorer: https://godbolt.org/z/q5ezG1MK3
% cat a.c
int *a;
int **b = &a;
char c;
int d, g;
void h(int i) {
long e[112];
e;
int *f = &i;
a = f;
}
void j() {
char *k[12];
for (; d; d++)
k[g] = &c;
}
int main() {
j();
h(-1);
__builtin_printf("**b=%d\n", **b);
}
%
% gcc-tk -fsanitize=address -O3 a.c && ./a.out
**b=-1
%
% gcc-tk -fsanitize=address -O2 a.c && ./a.out
=
==1==ERROR: AddressSanitizer: stack-use-after-return on address 0x7f0646b00020
at pc 0x00401148 bp 0x7ffed3f9a190 sp 0x7ffed3f9a188
READ of size 4 at 0x7f0646b00020 thread T0
#0 0x401147 in main /a.c:19
#1 0x7f064954c082 in __libc_start_main
(/lib/x86_64-linux-gnu/libc.so.6+0x24082) (BuildId:
1878e6b475720c7c51969e69ab2d276fae6d1dee)
#2 0x4011ad in _start (/output.s+0x4011ad) (BuildId:
7b9e8ee9f7af16e4a0a8a05fef54777844619617)
Address 0x7f0646b00020 is located in stack of thread T0 at offset 32 in frame
#0 0x40127f in h /a.c:5
This frame has 1 object(s):
[32, 36) 'i' (line 5) <== Memory access at offset 32 is inside 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-use-after-return /a.c:19 in main
Shadow bytes around the buggy address:
0x7f0646affd80: 00 00 00 00 00 00
...
%
[Bug sanitizer/108637] New: ASAN at -O2 misses a stack-use-after-scope
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108637
Bug ID: 108637
Summary: ASAN at -O2 misses a stack-use-after-scope
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 -O2 cannot detect the stack-use-after-scope.
This happens since GCC-11. GCC-10 and below work fine.
I understand that there is a type-incompatible warning. But I believe it should
not affect the ASAN anyway.
Compiler explorer: https://godbolt.org/z/WcbadP961
% cat a.c
char a, b, c;
short d;
int main() {
{
long e = a;
for (; b <= 0; b++) {
char *f;
d = 2;
for (; d; d--) {
int g = 111;
f = &g;
if (e)
c = 0;
}
*f += 1;
a = *f;
}
}
}
%
% gcc-tk -fsanitize=address -O2 a.c && ./a.out
%
% gcc-tk -fsanitize=address -O1 a.c && ./a.out
=
==1==ERROR: AddressSanitizer: stack-use-after-scope on address 0x7fb285e00020
at pc 0x00401272 bp 0x7ffda17739c0 sp 0x7ffda17739b8
READ of size 1 at 0x7fb285e00020 thread T0
#0 0x401271 in main /a.c:15
#1 0x7fb28883d082 in __libc_start_main
(/lib/x86_64-linux-gnu/libc.so.6+0x24082) (BuildId:
1878e6b475720c7c51969e69ab2d276fae6d1dee)
#2 0x4010bd in _start (/output.s+0x4010bd) (BuildId:
cb6e8e9c15b7d8e5515d7e6b8591d2b77b5f3e21)
Address 0x7fb285e00020 is located in stack of thread T0 at offset 32 in frame
#0 0x401185 in main /a.c:3
This frame has 1 object(s):
[32, 36) 'g' (line 10) <== Memory access at offset 32 is inside 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-use-after-scope /a.c:15 in main
Shadow bytes around the buggy address:
...
%
[Bug sanitizer/108637] ASAN at -O2 misses a stack-use-after-scope
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108637 --- Comment #2 from Li Shaohua --- (In reply to Andrew Pinski from comment #1) > PRE removes the load/stores from/to *f . > Basically the compiler is able to remove the use-after-scope usage with -O2 > and above. Well, this makes sense to me while in this case only -O2 not other opt levels did not report this use-after-scope usage.
[Bug sanitizer/108637] ASAN at -O2 misses a stack-use-after-scope
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108637 Li Shaohua changed: What|Removed |Added Resolution|INVALID |--- Status|RESOLVED|UNCONFIRMED --- Comment #3 from Li Shaohua --- (In reply to Li Shaohua from comment #2) > (In reply to Andrew Pinski from comment #1) > > PRE removes the load/stores from/to *f . > > Basically the compiler is able to remove the use-after-scope usage with -O2 > > and above. > > Well, this makes sense to me while in this case only -O2 not other opt > levels did not report this use-after-scope usage. I looked into this again and found that for GCC-12, it was indeed the case. But for the trunk, I indeed observed that PRE did not optimize away load/store. Compiler explorer: https://godbolt.org/z/sb658P1cM
[Bug sanitizer/108817] New: ASAN at -O3 failed to detect a global-buffer-overflow
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108817
Bug ID: 108817
Summary: ASAN at -O3 failed to detect a global-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 -O3 (GCC>=12) missed the global
buffer-overflow, while other opt levels detected it. GCC-11 can detect it at
all opt levels. Although I was using -O3, I indeed observed the overflow read
and the ASAN check in the assembly code.
Compiler explorer: https://godbolt.org/z/9Yenz8roT
% cat a.c
long a;
int b[3];
char c;
int main() {
int d;
a = 2;
for (; a >= 0; a--) {
d = 0;
for (; d <= 3; d++)
c = b[a+1];
}
return c;
}
%
% gcc-tk -O3 -fsanitize=address a.c && ./a.out
%
% gcc-tk -O2 -fsanitize=address a.c && ./a.out
=
==1==ERROR: AddressSanitizer: global-buffer-overflow on address 0x004041cc
at pc 0x0040112b bp 0x7ffd88ccd090 sp 0x7ffd88ccd088
READ of size 4 at 0x004041cc thread T0
#0 0x40112a in main /a.c:10
#1 0x7f8b3fad2082 in __libc_start_main
(/lib/x86_64-linux-gnu/libc.so.6+0x24082) (BuildId:
1878e6b475720c7c51969e69ab2d276fae6d1dee)
#2 0x40119d in _start (/a.s+0x40119d) (BuildId:
8f8919b865053b4da8e28daf8de45ed9390d0057)
0x004041cc is located 52 bytes before global variable 'a' defined in '/a.c'
(0x404200) of size 8
0x004041cc is located 0 bytes after global variable 'b' defined in '/a.c'
(0x4041c0) of size 12
SUMMARY: AddressSanitizer: global-buffer-overflow /a.c:10 in main
Shadow bytes around the buggy address:
0x00403f00: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x00403f80: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x00404000: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x00404080: 00 00 00 00 f9 f9 f9 f9 f9 f9 f9 f9 f9 f9 f9 f9
0x00404100: f9 f9 f9 f9 f9 f9 f9 f9 f9 f9 f9 f9 00 00 00 00
=>0x00404180: 01 f9 f9 f9 f9 f9 f9 f9 00[04]f9 f9 f9 f9 f9 f9
0x00404200: 00 f9 f9 f9 f9 f9 f9 f9 00 00 00 00 00 00 00 00
0x00404280: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x00404300: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x00404380: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x00404400: 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
...
%
[Bug sanitizer/108824] New: ASAN -O2/3 missed a stack-buffer-underflow since GCC-10
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108824
Bug ID: 108824
Summary: ASAN -O2/3 missed a stack-buffer-underflow since
GCC-10
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 -O2 missed the stack-buffer-underflow since
GCC-10, while -O3 missed it since GCC-8.
Clang can detect it at all opt levels.
Compiler explorer: https://godbolt.org/z/vM7bPq7de
% cat a.c
struct a {};
struct b {
unsigned c;
} g;
char d, f;;
int e=1, h;
void i();
void j() {
int k=0;
struct a l;
for (; h < 4; h++)
i(g, 0, &e, &k, 0);
}
void i(struct b p1, long p2, int *m, int *n, struct b o) {
*m = o.c > *(n - 1);
for (; f;)
for (; d;)
;
}
int main() {
j();
return e;
}
%
% gcc-tk -O2 -fsanitize=address a.c &&./a.out
%
% gcc-9 -O2 -fsanitize=address a.c &&./a.out
=
==1==ERROR: AddressSanitizer: stack-buffer-underflow on address 0x7ffda463e79c
at pc 0x004009e2 bp 0x7ffda463e6f0 sp 0x7ffda463e6e8
READ of size 4 at 0x7ffda463e79c thread T0
#0 0x4009e1 in i /a.c:19
#1 0x400a99 in j /a.c:15
#2 0x40074a in main /a.c:24
#3 0x7fc175a80082 in __libc_start_main
(/lib/x86_64-linux-gnu/libc.so.6+0x24082)
#4 0x4007bd in _start (/a.s+0x4007bd)
Address 0x7ffda463e79c is located in stack of thread T0 at offset 28 in frame
#0 0x4009ff in j /a.c:10
This frame has 1 object(s):
[32, 36) 'k' (line 11) <== Memory access at offset 28 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-underflow /a.c:19 in i
Shadow bytes around the buggy address:
0x1000348bfca0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x1000348bfcb0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x1000348bfcc0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x1000348bfcd0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x1000348bfce0: 00 00 00 00 f1 f1 f1 f1 04 f3 f3 f3 00 00 00 00
=>0x1000348bfcf0: f1 f1 f1[f1]04 f3 f3 f3 00 00 00 00 00 00 00 00
0x1000348bfd00: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x1000348bfd10: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x1000348bfd20: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x1000348bfd30: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x1000348bfd40: 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
...
%
[Bug sanitizer/108824] ASAN -O2/3 missed a stack-buffer-underflow since GCC-10
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108824 Li Shaohua changed: What|Removed |Added Resolution|--- |INVALID Status|UNCONFIRMED |RESOLVED --- Comment #1 from Li Shaohua --- Sorry, I checked the code and confirmed that the overflow operations were optimized out.
[Bug sanitizer/108864] New: Insufficient red zone in ASAN
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 0x00401291 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
=>0x7f6f0370: 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):
...
%
[Bug sanitizer/108903] New: ASAN may miss a global-buffer-overflow
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108903
Bug ID: 108903
Summary: ASAN may miss a global-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 -Os did not report the global-buffer-overflow
while other opt levels did.
$ cat a.c
int a, e, c;
short b;
static int *d = &e;
int main() {
for (; b < 4; b++) {
int *f = &a;
for (; c <= 7; c++) {
*f = *(d + 1);
if (*d)
break;
*f = 0;
}
a=*f;
}
return a;
}
$
$ gcc a.c -fsanitize=address -Os && ./a.out
$
$ gcc a.c -fsanitize=address -O3 && ./a.out
=
==1==ERROR: AddressSanitizer: global-buffer-overflow on address 0x00404244
at pc 0x0040119a bp 0x7fff990d2e40 sp 0x7fff990d2e38
READ of size 4 at 0x00404244 thread T0
#0 0x401199 in main /app/a.c:8
#1 0x7fc4eaa09082 in __libc_start_main
(/lib/x86_64-linux-gnu/libc.so.6+0x24082) (BuildId:
1878e6b475720c7c51969e69ab2d276fae6d1dee)
#2 0x4011fd in _start (/app/a.s+0x4011fd) (BuildId:
ffda4adec8a32a35ec5ae846f253cc2fcc431a06)
...
$
I realize that the statement `*f = *(d + 1)` may have been optimized out and it
is indeed according to the optimized tree:
$ gcc-tk a.c -Os -fsanitize=address -fdump-tree-optimized=/dev/stdout
...
bb 3> [local count: 1014686024]:
ivtmp.23_58 = ivtmp.23_34 + 1;
if (_3 != 0)
goto ; [5.50%]
else
goto ; [94.50%]
[local count: 55807731]:
_49 = (unsigned long) &MEM[(int *)&e + 4B];
_43 = _49 >> 3;
_10 = _43 + 2147450880;
..
$
So the ASAN checking branch won't be executed. However, when I check the
generated ASM, I find that the `e+4` has been used. I wonder if some later
passes promote the overflowed instructions from a dead part. If yes, this is
potentially very dangerous.
$ gcc-tk a.c -Os -fsanitize=address -S -o /dev/stdout
...
main:
movl$e+4, %edx <-- e+4 is used
movwb(%rip), %ax
pushq %rbx
xorl%ecx, %ecx
movq%rdx, %rbx
movle(%rip), %r11d
...
[Bug sanitizer/108904] New: ASAN at -O2/3 missed a global buffer overflow
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108904
Bug ID: 108904
Summary: ASAN at -O2/3 missed a global 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 -O2/3 missed the global-buffer-overflow.
Compiler explorer: https://godbolt.org/z/zjed8vzhj
% cat a.c
int a, b, c = 3, d;
static int *e = &c, *f, *g = &e;
short h, i;
int(j)(int k) {
return k==0 ?0: a;
}
int *l(int* p) { return &b; }
int main() {
for (; h >= 0; h--) {
b = j(*e);
if (*e | *(&d + 1))
++i;
}
f = l(g);
__builtin_printf("%d\n", i);
}
%
% gcc-tk -O2 -fsanitize=address -w a.c && ./a.out
1
% gcc-tk -O1 -fsanitize=address -w a.c && ./a.out
=
==1==ERROR: AddressSanitizer: global-buffer-overflow on address 0x00404424
at pc 0x004011fd bp 0x7ffe0ae032c0 sp 0x7ffe0ae032b8
READ of size 4 at 0x00404424 thread T0
#0 0x4011fc in main /app/a.c:11
#1 0x7fb7968aa082 in __libc_start_main
(/lib/x86_64-linux-gnu/libc.so.6+0x24082) (BuildId:
1878e6b475720c7c51969e69ab2d276fae6d1dee)
#2 0x4010bd in _start (/app/a.s+0x4010bd) (BuildId:
ad1fc5fb90a08d043b6c529370650d444b96c26e)
0x00404424 is located 60 bytes before global variable 'b' defined in
'/app/a.c' (0x404460) of size 4
0x00404424 is located 0 bytes after global variable 'd' defined in
'/app/a.c' (0x404420) of size 4
...
%
[Bug sanitizer/108963] New: ASAN produces wrong line number in the report
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108963
Bug ID: 108963
Summary: ASAN produces wrong line number in the report
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 -O1 and above always produces the wrong line
number. I've found quite some cases that have this issue.
Compiler explorer: https://godbolt.org/z/hscP9T78M
% cat a.c
union a {
int b;
};
char c;
int d;
static long e(int *f) {
for (; c <= 1;c++)
*(f + 1) |= 2;
return 0;
}
int main() {
union a g = {};
e(&d);
&g;
}
%
% gcc-tk -O0 -fsanitize=address a.c && ./a.out
=
==1==ERROR: AddressSanitizer: global-buffer-overflow on address 0x00404184
at pc 0x004011d6 bp 0x7ffea18cbe60 sp 0x7ffea18cbe58
READ of size 4 at 0x00404184 thread T0
#0 0x4011d5 in e /a.c:8
#1 0x4012f1 in main /a.c:13
...
%
% gcc-tk -O1 -fsanitize=address a.c && ./a.out
=
==1==ERROR: AddressSanitizer: global-buffer-overflow on address 0x00404144
at pc 0x00401289 bp 0x74114850 sp 0x74114848
READ of size 4 at 0x00404144 thread T0
#0 0x401288 in main /a.c:12
...
%
Maybe a fundunmentally similar to
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108023
[Bug sanitizer/109050] New: UBsan failed to detect out-of-bound at -O0/1/2/s
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109050
Bug ID: 109050
Summary: UBsan failed to detect out-of-bound at -O0/1/2/s
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, UBsan failed to detect the out-of-bound access at all
opt levels. Clang can detect it at all opt levels.
Compiler explorer: https://godbolt.org/z/TK35hvPrK
% cat a.c
long a;
int b;
int main() {
int c[4]={0, 1, 2, 3};
a = 0;
for (; a <= 2; a++)
c[a - 9806816] |= b;
}
%
% gcc-tk -O0 -fsanitize=undefined a.c && ./a.out
%
% gcc-tk -O1 -fsanitize=undefined a.c && ./a.out
%
% clang -O1 -fsanitize=undefined a.c && ./a.out
/a.c:7:5: runtime error: index -9806816 out of bounds for type 'int[4]'
...
% gcc-tk -v
Using built-in specs.
COLLECT_GCC=gcc-tk
COLLECT_LTO_WRAPPER=/zdata/shaoli/compilers/ccbuilder-compilers/gcc-7e9dd9de169034810b92d47bf78284db731fa5da/libexec/gcc/x86_64-pc-linux-gnu/13.0.1/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: ../configure --disable-multilib --disable-bootstrap
--enable-languages=c,c++
--prefix=/zdata/shaoli/compilers/ccbuilder-compilers/gcc-7e9dd9de169034810b92d47bf78284db731fa5da
Thread model: posix
Supported LTO compression algorithms: zlib
gcc version 13.0.1 20230221 (experimental) (GCC)
%
[Bug sanitizer/109107] New: UBsan since GCC-8 misses an integer-overflow
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109107
Bug ID: 109107
Summary: UBsan since GCC-8 misses an integer-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, UBsan since GCC-8 at -O1 and above misses the integer
overflow. GCC-7 can detect it at all opt levels.
Clang can detect it at all opt levels.
Compiler explorer: https://godbolt.org/z/Pez4jd5aj
% cat a.c
int a = -2147468918, c;
const long b = 676540;
int main() {
c = 1 + a - (short)b;
return c;
}
%
% gcc-tk -O1 -fsanitize=undefined a.c &&./a.out
%
% gcc-7 -O1 -fsanitize=undefined a.c &&./a.out
/a.c:4:15: runtime error: signed integer overflow: -2147468918 - 21179 cannot
be represented in type 'int'
%
[Bug sanitizer/105084] New: ASAN false positive on global-buffer-overflow
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105084
Bug ID: 105084
Summary: ASAN false positive on global-buffer-overflow
Product: gcc
Version: 12.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,
ASAN seems to falsely report global-buffer-overflow with "-O1" and above. I
tested with gcc trunk, 11.0, 10.0, and 9.0. They all reported the same issue. I
wonder if this behaviour is intended or not. For clang's ASAN, it does not
report anything on the program.
$
$cat a.c
int a[] = {3};
int b = 7;
main() {
unsigned int *c = &b;
*c = a[1];
}
$
$gcc -fsanitize=address -w -O0; ./a.out
$
$gcc -fsanitize=address -w -O1; ./a.out
==292501==ERROR: AddressSanitizer: global-buffer-overflow on address
0x55aff123e040 at pc 0x55aff123b218 bp 0x7ffd41151fd0 sp 0x7ffd41151fc0
READ of size 4 at 0x55aff123e040 thread T0
#0 0x55aff123b217 in main (/shared/oob/debug_wrong3/a.out+0x2217)
#1 0x7f3933a360b2 in __libc_start_main
(/lib/x86_64-linux-gnu/libc.so.6+0x240b2)
#2 0x55aff123b10d in _start (/shared/oob/debug_wrong3/a.out+0x210d)
0x55aff123e040 is located 32 bytes to the left of global variable 'ak' defined
in 'simple.c:26:16' (0x55aff123e060) of size 4
0x55aff123e040 is located 28 bytes to the right of global variable 'al' defined
in 'simple.c:27:16' (0x55aff123e020) of size 4
SUMMARY: AddressSanitizer: global-buffer-overflow
(/shared/oob/debug_wrong3/a.out+0x2217) in main
Shadow bytes around the buggy address:
0x0ab67e23fbb0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x0ab67e23fbc0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x0ab67e23fbd0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x0ab67e23fbe0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x0ab67e23fbf0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
=>0x0ab67e23fc00: 00 00 00 00 04 f9 f9 f9[f9]f9 f9 f9 04 f9 f9 f9
0x0ab67e23fc10: f9 f9 f9 f9 00 00 00 00 00 00 00 00 00 00 00 00
0x0ab67e23fc20: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x0ab67e23fc30: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x0ab67e23fc40: 00 00 00 00 00 00 00 00 00 00 00 f9 f9 f9 f9 f9
0x0ab67e23fc50: 04 f9 f9 f9 f9 f9 f9 f9 00 00 00 00 00 00 00 00
Shadow byte legend (one shadow byte represents 8 application bytes):
[Bug sanitizer/105084] ASAN false positive on global-buffer-overflow
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105084
--- Comment #1 from Li Shaohua ---
Sorry, the triggering program should be the following:
$cat a.c
int a[] = {3};
int b = 7;
main() {
unsigned int *c = &b;
*c = a[-1];
}
[Bug sanitizer/105084] ASAN false positive on global-buffer-overflow
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105084 --- Comment #3 from Li Shaohua --- Thanks a lot for your explanation. That makes sense to me :).
[Bug sanitizer/105107] New: false positive stack-buffer-overflow in ASAN
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105107
Bug ID: 105107
Summary: false positive stack-buffer-overflow in ASAN
Product: gcc
Version: 12.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, ASAN in gcc-O0 since 9.0 reported a
"stack-buffer-overflow", which it shouldn't.
$cat a.c
#define c(d, j) d = 5;
h=1;
*a=&h;
**b = &a;
int e;
fn1() {
int e=0;
int **f = &a;
*f = &e;
}
i() {
int g[9];
c(**b, )
}
main() {
fn1();
i();
}
$
$gcc -fsanitize=address -O0 a.c;./a.out
==1==ERROR: AddressSanitizer: stack-buffer-overflow on address 0x7ffef6656070
at pc 0x00401390 bp 0x7ffef6656000 sp 0x7ffef6655ff8
WRITE of size 4 at 0x7ffef6656070 thread T0
#0 0x40138f in i /app/example.c:13
#1 0x4013e8 in main /app/example.c:17
#2 0x7f5a7f21c0b2 in __libc_start_main
(/lib/x86_64-linux-gnu/libc.so.6+0x240b2)
#3 0x4010ed in _start (/app/output.s+0x4010ed)
[Bug sanitizer/105107] false positive stack-buffer-overflow in ASAN
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105107 --- Comment #2 from Li Shaohua --- Thanks for your prompt reply. The warning messages only appeared for -O0 and -O3, not for -O1 and -O2. I wonder this might also be an issue.
[Bug sanitizer/105141] New: #pragma pack(1) causes incorrect UBSAN warning
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105141
Bug ID: 105141
Summary: #pragma pack(1) causes incorrect UBSAN warning
Product: gcc
Version: 12.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, UBSAN would warn a "load of misaligned address".
Removing #pragma pack(1) will make the warning away.
$cat a.c
#pragma pack(1)
struct {
char a;
int b;
} c;
int *d = &c.b;
int main() {
__builtin_printf("%d\n", *d);
}
$
$gcc -fsanitize=undefined -O0 -w a.c;./a.out
~/a.c:8:5: runtime error: load of misaligned address 0x004040ca for type
'int', which requires 4 byte alignment
0x004040ca: 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
^
0
$
$
[Bug sanitizer/105141] #pragma pack(1) causes incorrect UBSAN warning
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105141
--- Comment #3 from Li Shaohua ---
Thanks for your explanation.
struct {
char a[3];
int b;
} c;
When I did this, the warning did not show up. Should it still be misaligned?
[Bug sanitizer/105141] #pragma pack(1) causes incorrect UBSAN warning
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105141
--- Comment #5 from Li Shaohua ---
No, I meant
#pragma pack(1)
struct {
char a[3];
int b;
} c;
[Bug sanitizer/105155] New: -fsanitize=signed-integer-overflow failed to check an overflow
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105155
Bug ID: 105155
Summary: -fsanitize=signed-integer-overflow failed to check an
overflow
Product: gcc
Version: 12.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 was expecting the sanitizer to warn about the integer
overflow. I checked with clang's UBSAN, which would warn however.
$cat a.c
#include
int foo(int a) {
return INT_MAX + (a>0?1:-1);
}
int main() {
__builtin_printf("%d\n", foo(1));
}
$
$gcc -fsanitize=signed-integer-overflow -w -O0 a.c;./a.out
-2147483648
$
[Bug sanitizer/105155] -fsanitize=signed-integer-overflow failed to check an overflow
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105155
--- Comment #2 from Li Shaohua ---
(In reply to Richard Biener from comment #1)
> We fold this already before gimplification to
>
> ;; Function foo (null)
> ;; enabled by -tree-original
>
>
> {
> return a > 0 ? -2147483648(OVF) : 2147483646;
> }
Does this mean that it is not a bug?
[Bug sanitizer/105396] New: missed stack-buffer-overflow by -O0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105396
Bug ID: 105396
Summary: missed stack-buffer-overflow by -O0
Product: gcc
Version: 12.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, `gcc -fsanitize=address -O0` misses the
buffer-overflow, while `gcc -fsanitize=address -O3` catches it.
$cat a.c
int main() {
int a;
int *b[1];
int c[10];
int d[1][1];
for (a = 0; a < 1; a++)
d[1][a] = 0;
}
$
$gcc -fsanitize=address -O0;./a.out
$
$gcc -fsanitize=address -O3;./a.out
==1==ERROR: AddressSanitizer: stack-buffer-overflow on address 0x7fffda35c0d4
at pc 0x00401104 bp 0x7fffda35c0a0 sp 0x7fffda35c098
WRITE of size 4 at 0x7fffda35c0d4 thread T0
#0 0x401103 in main /app/example.c:8
#1 0x7fc3351380b2 in __libc_start_main
(/lib/x86_64-linux-gnu/libc.so.6+0x240b2)
#2 0x40118d in _start (/app/output.s+0x40118d)
Address 0x7fffda35c0d4 is located in stack of thread T0 at offset 36 in frame
#0 0x40107f in main /app/example.c:2
This frame has 1 object(s):
[32, 36) 'd' (line 6) <== Memory access at offset 36 overflows 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 /app/example.c:8 in main
Shadow bytes around the buggy address:
0x10007b4637c0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x10007b4637d0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x10007b4637e0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x10007b4637f0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x10007b463800: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
=>0x10007b463810: 00 00 00 00 00 00 f1 f1 f1 f1[04]f3 f3 f3 00 00
0x10007b463820: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x10007b463830: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x10007b463840: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x10007b463850: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x10007b463860: 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/105405] New: missed buffer-overflow in -O0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105405
Bug ID: 105405
Summary: missed buffer-overflow in -O0
Product: gcc
Version: 12.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, `gcc -fsanitize=address -O0` would miss the report,
while `gcc -fsanitize=address -O3` would not.
$cat a.c
main() {
int a[1][1];
{
int *b[1];
}
a[1][3]++;
}
$
$gcc -fsanitize=address -w -O0 a.c ; ./a.out
$
$gcc -fsanitize=address -w -O3 a.c ; ./a.out
=
==6342==ERROR: AddressSanitizer: stack-buffer-overflow on address
0x7f8843a00030 at pc 0x004010f9 bp 0x7fff0b7f6a40 sp 0x7fff0b7f6a38
READ of size 4 at 0x7f8843a00030 thread T0
#0 0x4010f8 in main
(/shared/mutate/array/trial_new/work0/debug40/a.out+0x4010f8)
#1 0x7f8845c570b2 in __libc_start_main
(/lib/x86_64-linux-gnu/libc.so.6+0x240b2)
#2 0x40117d in _start
(/shared/mutate/array/trial_new/work0/debug40/a.out+0x40117d)
Address 0x7f8843a00030 is located in stack of thread T0 at offset 48 in frame
#0 0x40107f in main
(/shared/mutate/array/trial_new/work0/debug40/a.out+0x40107f)
This frame has 1 object(s):
[32, 36) 'a' (line 2) <== Memory access at offset 48 overflows 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
(/shared/mutate/array/trial_new/work0/debug40/a.out+0x4010f8) in main
Shadow bytes around the buggy address:
0x0ff188737fb0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x0ff188737fc0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x0ff188737fd0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x0ff188737fe0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x0ff188737ff0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
=>0x0ff188738000: f1 f1 f1 f1 04 f3[f3]f3 00 00 00 00 00 00 00 00
0x0ff188738010: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x0ff188738020: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x0ff188738030: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x0ff188738040: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x0ff188738050: 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
==6342==ABORTING
[Bug sanitizer/105405] missed buffer-overflow in -O0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105405 --- Comment #2 from Li Shaohua --- Yeah, I've tried that fix. It didn't fix the issue though.
[Bug sanitizer/105405] missed buffer-overflow in -O0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105405
--- Comment #4 from Li Shaohua ---
@Jakub, I agree with you that the above test case may access too far from the
red zone. However, for the below test case, I cannot figure out why -O0 again
did not report anything. As a user, I would think that *j[5][1]* did not reach
too far from the red zone although it might do according to your explanation.
$cat a.c
struct a {
int b[9];
long h
};
int i;
struct a j[6][1];
main() {
if (j[5][1].h) {
char k[4];
k;
}
}
$
[Bug sanitizer/106368] New: ASan fails to report an error.
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 0x00404134 at pc
0x004011a8 bp 0x7ffeadf39d20 sp 0x7ffeadf39d18
READ of size 8 at 0x00404134 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)
0x00404138 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:
0x800787d0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x800787e0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x800787f0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x80078800: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x80078810: 00 00 00 00 f9 f9 f9 f9 f9 f9 f9 f9 00 00 00 00
=>0x80078820: 00 00 00 00 00 00[00]f9 f9 f9 f9 f9 00 00 00 00
0x80078830: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x80078840: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x80078850: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x80078860: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x80078870: 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/106558] New: ASan failed to detect a global-buffer-overflow
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106558
Bug ID: 106558
Summary: ASan failed to detect a global-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, `gcc-trunk -O1 -fsanitize=address` failed to detect the
global-buffer-overflow, while other opt flags (-O0, -O2, and -O3) can.
$cat a.c
int a;
int *b = &a;
int **c = &b;
int d[1];
int *e = &d[1];
static int f(int *g) {
*b = e;
*c = e;
*b = 2;
*g = 2;
}
int main() {
f(b);
return *b;
}
$
$gcc-trunk -O1 -fsanitize=address -w -g && ./a.out
$
$gcc-trunk -O3 -fsanitize=address -w -g && ./a.out
=
==1==ERROR: AddressSanitizer: global-buffer-overflow on address 0x00404304
at pc 0x0040110d bp 0x7c438ae0 sp 0x7c438ad8
WRITE of size 4 at 0x00404304 thread T0
#0 0x40110c in f /app/a.c:10
#1 0x40110c in main /app/a.c:14
#2 0x7f9bc6e1a0b2 in __libc_start_main
(/lib/x86_64-linux-gnu/libc.so.6+0x240b2) (BuildId:
9fdb74e7b217d06c93172a8243f8547f947ee6d1)
#3 0x40117d in _start (/app/output.s+0x40117d) (BuildId:
55182140539c37abf57e49748b511b560966f7c4)
0x00404304 is located 60 bytes to the left of global variable 'a' defined
in '/app/a.c:1:5' (0x404340) of size 4
0x00404304 is located 0 bytes to the right of global variable 'd' defined
in '/app/a.c:4:5' (0x404300) of size 4
SUMMARY: AddressSanitizer: global-buffer-overflow /app/a.c:10 in f
Shadow bytes around the buggy address:
0x80078810: 00 f9 f9 f9 f9 f9 f9 f9 00 f9 f9 f9 f9 f9 f9 f9
0x80078820: 00 f9 f9 f9 f9 f9 f9 f9 00 00 00 00 00 00 00 00
0x80078830: 00 00 00 00 f9 f9 f9 f9 f9 f9 f9 f9 f9 f9 f9 f9
0x80078840: f9 f9 f9 f9 f9 f9 f9 f9 f9 f9 f9 f9 f9 f9 f9 f9
0x80078850: f9 f9 f9 f9 f9 f9 f9 f9 f9 f9 f9 f9 00 00 00 00
=>0x80078860:[04]f9 f9 f9 f9 f9 f9 f9 04 f9 f9 f9 f9 f9 f9 f9
0x80078870: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x80078880: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x80078890: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x800788a0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x800788b0: 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/106591] New: ASan at -O1 fails to detect a global buffer overflow
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106591
Bug ID: 106591
Summary: ASan at -O1 fails to detect a global 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, `gcc-trunk -O1 -fsanitize=address` failed to detect the
global-buffer-overflow, while other opt flags (-O0, -O2, and -O3) can.
$cat a.c
a;
*b = &a, *d = &a;
volatile static **c = &b;
int foo(int p1, int p2) {
return p1 % p2;
}
static int* e() {
**c;
int *f = &a;
return f + 1;
}
int main() {
*c = e();
*d = 1;
foo(**c, *d);
}
$
$gcc-trunk -O1 -fsanitize=address -w -g && ./a.out
$
$gcc-trunk -O2 -fsanitize=address -w -g && ./a.out
=
==1==ERROR: AddressSanitizer: global-buffer-overflow on address 0x00404224
at pc 0x0040113b bp 0x73ecdca0 sp 0x73ecdc98
READ of size 4 at 0x00404224 thread T0
#0 0x40113a in main /app/a.c:16
#1 0x7f68868750b2 in __libc_start_main
(/lib/x86_64-linux-gnu/libc.so.6+0x240b2) (BuildId:
9fdb74e7b217d06c93172a8243f8547f947ee6d1)
#2 0x4011ad in _start (/app/output.s+0x4011ad) (BuildId:
db3aa359dc97f1881309f971535063412033e172)
0x00404224 is located 0 bytes to the right of global variable 'a' defined
in '/app/a.c:1:1' (0x404220) of size 4
SUMMARY: AddressSanitizer: global-buffer-overflow /app/a.c:16 in main
Shadow bytes around the buggy address:
0x800787f0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x80078800: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x80078810: 00 f9 f9 f9 f9 f9 f9 f9 00 f9 f9 f9 f9 f9 f9 f9
0x80078820: 00 00 00 00 00 00 00 00 f9 f9 f9 f9 f9 f9 f9 f9
0x80078830: f9 f9 f9 f9 f9 f9 f9 f9 f9 f9 f9 f9 f9 f9 f9 f9
=>0x80078840: 00 00 00 00[04]f9 f9 f9 f9 f9 f9 f9 00 00 00 00
0x80078850: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x80078860: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x80078870: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x80078880: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x80078890: 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 c/106892] New: Wrong code at -O3 on x86_64-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106892
Bug ID: 106892
Summary: Wrong code at -O3 on x86_64-linux-gnu
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: shaohua.li at inf dot ethz.ch
Target Milestone: ---
$ gcc-tk -v
Using built-in specs.
COLLECT_GCC=gcc-tk
COLLECT_LTO_WRAPPER=/zdata/shaoli/compilers/ccbuilder-compilers/gcc-75f59441cd63a1d07e86d70d59c518049f53904f/libexec/gcc/x86_64-pc-linux-gnu/13.0.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: ../configure --disable-multilib --disable-bootstrap
--enable-languages=c,c++
--prefix=/zdata/shaoli/compilers/ccbuilder-compilers/gcc-75f59441cd63a1d07e86d70d59c518049f53904f
Thread model: posix
Supported LTO compression algorithms: zlib
gcc version 13.0.0 20220830 (experimental) (GCC)
$
$ gcc-tk -w -O0 simple.c && ./a.out
0
$ gcc-tk -w -O0 simple.c && ./a.out
3
$
$ cat simple.c
a, b, c, d, e;
f[8];
g() {
while (a)
a >>= 4;
}
h(i) {
if (i >= '0')
return i - '0';
}
j(i) {
b = 2;
for (; g() <= 7; b++)
if (i) {
for (; e <= 7; e++) {
c = 1;
for (; c <= 7; c++) {
d = h(b + 48);
f[-d + 4] ^= 3;
}
}
return;
}
}
main() {
j(1);
printf("%d\n", f[2]);
}
$
[Bug c/106892] Wrong code at -O3 on x86_64-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106892
--- Comment #3 from Li Shaohua ---
Yes, I reduced it too much. Here is the new one with return value in g()
function.
a, b, c, d, e;
f[8];
g() {
while (a)
a >>= 4;
return 0;
}
h(i) {
if (i >= '0')
return i - '0';
}
j(i) {
b = 2;
for (; g() <= 7; b++)
if (i) {
for (; e <= 7; e++) {
c = 1;
for (; c <= 7; c++) {
d = h(b + 48);
f[-d + 4] ^= 3;
}
}
return;
}
}
main() {
j(1);
printf("%d\n", f[2]);
}
[Bug c/106995] New: gcc-trunk crash at -O2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106995
Bug ID: 106995
Summary: gcc-trunk crash at -O2
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: shaohua.li at inf dot ethz.ch
Target Milestone: ---
% gcc-tk -v
Using built-in specs.
COLLECT_GCC=gcc-tk
COLLECT_LTO_WRAPPER=/zdata/shaoli/compilers/ccbuilder-compilers/gcc-1e4c7e870e2a3a059568565196a8f3b8c9de1fa4/libexec/gcc/x86_64-pc-linux-gnu/13.0.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: ../configure --disable-multilib --disable-bootstrap
--enable-languages=c,c++
--prefix=/zdata/shaoli/compilers/ccbuilder-compilers/gcc-1e4c7e870e2a3a059568565196a8f3b8c9de1fa4
Thread model: posix
Supported LTO compression algorithms: zlib
gcc version 13.0.0 20220915 (experimental) (GCC)
%
% gcc-tk -w -O1 a.c
during RTL pass: expand
simple.c: In function ‘i’:
simple.c:4:1: internal compiler error: in expand_LOOP_VECTORIZED, at
internal-fn.cc:2729
4 | i() {
| ^
0x2033eee internal_error(char const*, ...)
???:0
0x998592 fancy_abort(char const*, int, char const*)
???:0
Please submit a full bug report, with preprocessed source (by using
-freport-bug).
Please include the complete backtrace with any bug report.
See
[Bug tree-optimization/106995] gcc-trunk crash at -O2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106995 --- Comment #1 from Li Shaohua --- Sorry, it should be `gcc-tk -w -O2 a.c`
[Bug sanitizer/107086] New: gcc trunkc at -O1 failed to detect a stack-use-after-return
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107086
Bug ID: 107086
Summary: gcc trunkc at -O1 failed to detect a
stack-use-after-return
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: ---
%gcc-tk -v
Using built-in specs.
COLLECT_GCC=gcc-tk
COLLECT_LTO_WRAPPER=/zdata/shaoli/compilers/ccbuilder-compilers/gcc-519196a27cf534e94f158733b25a4f9d10737031/libexec/gcc/x86_64-pc-linux-gnu/13.0.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: ../configure --disable-multilib --disable-bootstrap
--enable-languages=c,c++
--prefix=/zdata/shaoli/compilers/ccbuilder-compilers/gcc-519196a27cf534e94f158733b25a4f9d10737031
Thread model: posix
Supported LTO compression algorithms: zlib
gcc version 13.0.0 20220921 (experimental) (GCC)
%
%cat a.c
int a, b;
int *c;
int d() { return 0; }
static int e(int f) {
int h[144];
for (; b;)
h;
for (; a >= 0; a = -2)
c = &f;
return f;
}
int main() {
e(0);
*c = 0;
if (d()) {
int g[28];
g;
}
}
%
%
%gcc-tk -O1 -w -fsanitize=address a.c && ./a.out
%
%gcc-tk -O2 -w -fsanitize=address a.c && ./a.out
=
==491884==ERROR: AddressSanitizer: stack-use-after-return on address
0x7f9cd120 at pc 0x004010e1 bp 0x7ffe4ecb6150 sp 0x7ffe4ecb6148
WRITE of size 4 at 0x7f9cd120 thread T0
#0 0x4010e0 in main
/zdata/shaoli/SanitizerFuzz/csmith-only/asan/dangling-ptr-deref-prob-10/bugs/gcc_work102_8/a.c:14
#1 0x7f9cd3a71082 in __libc_start_main
(/lib/x86_64-linux-gnu/libc.so.6+0x24082) (BuildId:
1878e6b475720c7c51969e69ab2d276fae6d1dee)
#2 0x40114d in _start
(/zdata/shaoli/SanitizerFuzz/csmith-only/asan/dangling-ptr-deref-prob-10/bugs/gcc_work102_8/a.out+0x40114d)
Address 0x7f9cd120 is located in stack of thread T0 at offset 32 in frame
#0 0x40121f in e
/zdata/shaoli/SanitizerFuzz/csmith-only/asan/dangling-ptr-deref-prob-10/bugs/gcc_work102_8/a.c:4
This frame has 1 object(s):
[32, 36) 'f' (line 4) <== Memory access at offset 32 is inside 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-use-after-return
/zdata/shaoli/SanitizerFuzz/csmith-only/asan/dangling-ptr-deref-prob-10/bugs/gcc_work102_8/a.c:14
in main
Shadow bytes around the buggy address:
0x0ff41a1f7fb0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x0ff41a1f7fc0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x0ff41a1f7fd0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x0ff41a1f7fe0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x0ff41a1f7ff0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
=>0x0ff41a1f8000: f5 f5 f5 f5[f5]f5 f5 f5 00 00 00 00 00 00 00 00
0x0ff41a1f8010: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x0ff41a1f8020: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x0ff41a1f8030: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x0ff41a1f8040: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x0ff41a1f8050: 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
==491884==ABORTING
%
Compiler explorer: https://godbolt.org/z/rn9qjrb5K
>From the assembly code, we can see that the reason probably is the function
`e()` got inlined so that the stack variable didn't get instrumented.
[Bug c/107176] New: Wrong code at -O0/-Os on x86_64-pc-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107176
Bug ID: 107176
Summary: Wrong code at -O0/-Os on x86_64-pc-linux-gnu
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: shaohua.li at inf dot ethz.ch
Target Milestone: ---
%gcc-tk -v
Using built-in specs.
COLLECT_GCC=gcc-tk
COLLECT_LTO_WRAPPER=/zdata/shaoli/compilers/ccbuilder-compilers/gcc-b48d7ff3570fa0ebe7790275cf020d8885120338/libexec/gcc/x86_64-pc-linux-gnu/13.0.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: ../configure --disable-multilib --disable-bootstrap
--enable-languages=c,c++
--prefix=/zdata/shaoli/compilers/ccbuilder-compilers/gcc-b48d7ff3570fa0ebe7790275cf020d8885120338
Thread model: posix
Supported LTO compression algorithms: zlib
gcc version 13.0.0 20220928 (experimental) (GCC)
%
%gcc-tk -O0 a.c && ./a.out
1073741824
%
%gcc-tk -Os a.c && ./a.out
0
%
%cat a.c
int a;
long b;
long c(unsigned d) {
return d;
}
void e(d) {
a = d;
}
int main() {
b = 0;
for (; b < 1; b = c(b - 90) + 90 + 1)
;
e(b >> 2);
printf("%d\n", a);
}
%
Compiler explorer: https://godbolt.org/z/zzMdosoKj
[Bug c/107246] New: gcc trunk crash in verify_gimple_in_cfg
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107246
Bug ID: 107246
Summary: gcc trunk crash in verify_gimple_in_cfg
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: shaohua.li at inf dot ethz.ch
Target Milestone: ---
% gcc-tk -v
Using built-in specs.
COLLECT_GCC=gcc-tk
COLLECT_LTO_WRAPPER=/zdata/shaoli/compilers/ccbuilder-compilers/gcc-7c059880fca175589efc8e06ef458020a005658d/libexec/gcc/x86_64-pc-linux-gnu/13.0.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: ../configure --disable-multilib --disable-bootstrap
--enable-languages=c,c++
--prefix=/zdata/shaoli/compilers/ccbuilder-compilers/gcc-7c059880fca175589efc8e06ef458020a005658d
Thread model: posix
Supported LTO compression algorithms: zlib
gcc version 13.0.0 20221013 (experimental) (GCC)
%
% gcc-tk -w -O0 a.c
%
% gcc-tk -w -O3 a.c
a.c: In function ‘e’:
a.c:8:1: error: invalid position or size operand to ‘bit_field_ref’
8 | e() {
| ^
_ifc__16 = BIT_FIELD_REF <_ifc__15, 12, 0xffc0>;
during GIMPLE pass: ifcvt
a.c:8:1: internal compiler error: verify_gimple failed
0x205825e internal_error(char const*, ...)
???:0
0x10890f1 verify_gimple_in_cfg(function*, bool)
???:0
Please submit a full bug report, with preprocessed source (by using
-freport-bug).
Please include the complete backtrace with any bug report.
See
[Bug c/107257] New: Wrong code at -O2 on x86_64-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107257
Bug ID: 107257
Summary: Wrong code at -O2 on x86_64-linux-gnu
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: shaohua.li at inf dot ethz.ch
Target Milestone: ---
% gcc-tk -v
Using built-in specs.
COLLECT_GCC=gcc-tk
COLLECT_LTO_WRAPPER=/zdata/shaoli/compilers/ccbuilder-compilers/gcc-9f0d4adabe2035886a1aa8d2ca990a90de000613/libexec/gcc/x86_64-pc-linux-gnu/13.0.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: ../configure --disable-multilib --disable-bootstrap
--enable-languages=c,c++
--prefix=/zdata/shaoli/compilers/ccbuilder-compilers/gcc-9f0d4adabe2035886a1aa8d2ca990a90de000613
Thread model: posix
Supported LTO compression algorithms: zlib
gcc version 13.0.0 20221013 (experimental) (GCC)
%
% gcc-tk -w -O0 a.c && ./a.out
2
% gcc-tk -w -O2 a.c && ./a.out
0
%
% cat a.c
l;
m;
static signed char n();
s() { n(); }
signed char n(u) {
for (; u <= 2; u++) {
l = 2;
for (; l ; l--) {
m = 2;
for (; m; m--)
if (u)
break;
}
}
}
main() {
s(2);
printf("%d\n", m);
}
%
Compiler explorer: https://godbolt.org/z/z5Mhxaz9E
[Bug sanitizer/107258] New: ASAN at -O1 failed to detect a stack-under-flow
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107258
Bug ID: 107258
Summary: ASAN at -O1 failed to detect a stack-under-flow
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: ---
ASAN with -O1/-Os failed to detect the stack-buffer-underflow, while
-O0/-O2/-O3 can.
% gcc-tk -v
Using built-in specs.
COLLECT_GCC=gcc-tk
COLLECT_LTO_WRAPPER=/zdata/shaoli/compilers/ccbuilder-compilers/gcc-99da523359e933385484eb3b8f854a98f1b4/libexec/gcc/x86_64-pc-linux-gnu/13.0.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: ../configure --disable-multilib --disable-bootstrap
--enable-languages=c,c++
--prefix=/zdata/shaoli/compilers/ccbuilder-compilers/gcc-99da523359e933385484eb3b8f854a98f1b4
Thread model: posix
Supported LTO compression algorithms: zlib
gcc version 13.0.0 20221013 (experimental) (GCC)
%
% cat a.c
int a = -5, c, d;
static int f() {
int b[10];
printf("%d", b[a]);
}
int h() {
for (; c;) {
int *e[3];
e;
}
}
int main() {
int g[4];
g[d] = f();
h();
}
%
% gcc-tk -w -O1 -fsanitize=address a.c && ./a.out
0
% gcc-tk -w -O3 -fsanitize=address a.c && ./a.out
=
==929009==ERROR: AddressSanitizer: stack-buffer-overflow on address
0x7fabc520007c at pc 0x0040125d bp 0x7ffe232d2c00 sp 0x7ffe232d2bf8
READ of size 4 at 0x7fabc520007c thread T0
#0 0x40125c in f /zdata/shaoli/ubfuzz/synthesizer/debug/a.c:4
#1 0x40125c in main /zdata/shaoli/ubfuzz/synthesizer/debug/a.c:14
#2 0x7fabc79a8082 in __libc_start_main
(/lib/x86_64-linux-gnu/libc.so.6+0x24082) (BuildId:
1878e6b475720c7c51969e69ab2d276fae6d1dee)
#3 0x4012fd in _start
(/zdata/shaoli/ubfuzz/synthesizer/debug/a.out+0x4012fd)
Address 0x7fabc520007c is located in stack of thread T0 at offset 124 in frame
#0 0x4010df in main /zdata/shaoli/ubfuzz/synthesizer/debug/a.c:12
This frame has 3 object(s):
[48, 64) 'g' (line 13)
[80, 104) 'e' (line 8)
[144, 184) 'b' (line 3) <== Memory access at offset 124 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
/zdata/shaoli/ubfuzz/synthesizer/debug/a.c:4 in f
Shadow bytes around the buggy address:
0x0ff5f8a37fb0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x0ff5f8a37fc0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x0ff5f8a37fd0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x0ff5f8a37fe0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x0ff5f8a37ff0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
=>0x0ff5f8a38000: f1 f1 f1 f1 f1 f1 00 00 f2 f2 00 00 00 f2 f2[f2]
0x0ff5f8a38010: f2 f2 00 00 00 00 00 f3 f3 f3 f3 f3 00 00 00 00
0x0ff5f8a38020: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x0ff5f8a38030: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x0ff5f8a38040: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x0ff5f8a38050: 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
==929009==ABORTING
%
Compiler explorer: https://godbolt.org/z/Gea6cr9E1
[Bug c/107257] Wrong code at -O2 on x86_64-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107257
Li Shaohua changed:
What|Removed |Added
Resolution|INVALID |---
Status|RESOLVED|NEW
--- Comment #4 from Li Shaohua ---
Hi,
Sorry for my previous over-reduced test case. Here is a well-formed reduction:
```
void printf();
int a, b, c;
int d[3];
int e(int f, int g, int k, int l, int m, int n) {
int h = 4 * f + 2 * (g + l + n) + k + m, j = h >> 4;
return j;
}
void o(int f) {
int i = 0;
for (; i < 3; i++)
d[i] = 4279432140;
for (; - 72 + f - -72 <= 2; f++) {
a = 2;
for (; a >= 0; a--) {
b = 2;
for (; b >= 0; b--) {
int p = !(d[b] > 0 != e(10, 29, 42, 74, 89, -68) + f - 15);
if (p)
break;
}
if (f)
break;
}
}
}
void q() {
int i = 0;
o(0);
if (c)
for (; i < 1;)
for (; i < 1; i++)
;
}
int main() {
q();
printf("%d\n", b);
}
```
Compiler explorer: https://godbolt.org/z/bjjW5q17r
[Bug c/107293] New: Wrong code at -Os on x86_64-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107293
Bug ID: 107293
Summary: Wrong code at -Os on x86_64-linux-gnu
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: shaohua.li at inf dot ethz.ch
Target Milestone: ---
% gcc-tk -v
Using built-in specs.
COLLECT_GCC=gcc-tk
COLLECT_LTO_WRAPPER=/zdata/shaoli/compilers/ccbuilder-compilers/gcc-acdb24166d13d87c374e578d2ad5d58249171930/libexec/gcc/x86_64-pc-linux-gnu/13.0.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: ../configure --disable-multilib --disable-bootstrap
--enable-languages=c,c++
--prefix=/zdata/shaoli/compilers/ccbuilder-compilers/gcc-acdb24166d13d87c374e578d2ad5d58249171930
Thread model: posix
Supported LTO compression algorithms: zlib
gcc version 13.0.0 20221017 (experimental) (GCC)
%
% gcc-tk -w -O0 a.c && ./a.out
1
% gcc-tk -w -Os a.c && ./a.out
0
% cat a.c
short a;
int b[1];
int c(int p) {
return (p < 0) ? 0 : 10 + ((p / 100 - 16) / 4);
}
void f(int n) {
while (1) {
int m = n;
while ((m ) )
m /= 2;
break;
}
}
void g() {
int h = a = 0;
for (; h + a <= 0; a++) {
if (b[c(a - 6)])
break;
f(a);
}
}
int main() {
g();
__builtin_printf("%d\n", a);
}
%
Compiler explorer: https://godbolt.org/z/e7sssT7cq
[Bug c/103406] New: gcc -O0 behaves differently on "DBL_MAX related operations" than gcc -O1 and above
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103406
Bug ID: 103406
Summary: gcc -O0 behaves differently on "DBL_MAX related
operations" than gcc -O1 and above
Product: gcc
Version: 11.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: shaohua.li at inf dot ethz.ch
Target Milestone: ---
Hi there,
I found that for a piece of code, gcc would give out different results when
compiled with different opt flags.
- gcc version: 11.1.0
- Platform: Ubuntu 20.04, x86_64
$gcc a.c -O0; ./a.out
nan
$
$
$gcc a.c -O1; ./a.out
-nan
$
$
$cat a.c
#include
#include
#define INFINITY (DBL_MAX+DBL_MAX)
#define NAN (INFINITY-INFINITY)
void main() {
double x = -NAN;
double y = NAN;
double z = x + y;
printf("%lf\n", z);
}
[Bug c/107387] New: gcc trunk -O2 crashes when enable UBSan
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107387
Bug ID: 107387
Summary: gcc trunk -O2 crashes when enable UBSan
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: shaohua.li at inf dot ethz.ch
Target Milestone: ---
% gcc-tk -v
Using built-in specs.
COLLECT_GCC=gcc-tk
COLLECT_LTO_WRAPPER=/zdata/shaoli/compilers/ccbuilder-compilers/gcc-99da523359e933385484eb3b8f854a98f1b4/libexec/gcc/x86_64-pc-linux-gnu/13.0.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: ../configure --disable-multilib --disable-bootstrap
--enable-languages=c,c++
--prefix=/zdata/shaoli/compilers/ccbuilder-compilers/gcc-99da523359e933385484eb3b8f854a98f1b4
Thread model: posix
Supported LTO compression algorithms: zlib
gcc version 13.0.0 20221013 (experimental) (GCC)
%
% gcc-tk -fsanitize=undefined -O2 a.c
a.c: In function ‘m’:
a.c:8:59: warning: division by zero [-Wdiv-by-zero]
8 | static inline __attribute__((always_inline)) void m() { 0 / 0; }
| ^
during GIMPLE pass: slp
a.c: In function ‘p.isra’:
a.c:31:7: internal compiler error: in to_sreal_scale, at profile-count.cc:339
31 | void *p() {
| ^
0x2059aee internal_error(char const*, ...)
???:0
0x99f3c4 fancy_abort(char const*, int, char const*)
???:0
0x1310657 vect_optimize_slp_pass::start_choosing_layouts()
???:0
0x13118af vect_optimize_slp_pass::run()
???:0
0x1319cd9 vect_slp_function(function*)
???:0
Please submit a full bug report, with preprocessed source (by using
-freport-bug).
Please include the complete backtrace with any bug report.
See
[Bug c/107407] New: Wrong code at -Os on x86_64-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107407
Bug ID: 107407
Summary: Wrong code at -Os on x86_64-linux-gnu
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: shaohua.li at inf dot ethz.ch
Target Milestone: ---
% gcc-tk -v
Using built-in specs.
COLLECT_GCC=gcc-tk
COLLECT_LTO_WRAPPER=/zdata/shaoli/compilers/ccbuilder-compilers/gcc-97d1ed67fc6a5773c8c00875bfa3616a457cf5f9/libexec/gcc/x86_64-pc-linux-gnu/13.0.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: ../configure --disable-multilib --disable-bootstrap
--enable-languages=c,c++
--prefix=/zdata/shaoli/compilers/ccbuilder-compilers/gcc-97d1ed67fc6a5773c8c00875bfa3616a457cf5f9
Thread model: posix
Supported LTO compression algorithms: zlib
gcc version 13.0.0 20221024 (experimental) (GCC)
%
% gcc-tk -O0 a.c && ./a.out
3
0
0
0
% gcc-tk -Os a.c && ./a.out
0
0
0
0
% cat a.c
int printf(const char *, ...);
int *a;
static int **b = &a;
int c[4];
int d;
int e(int);
static int f(char, int);
void g() { e((f(0, 0), 0)); }
int e(int h) { *a = 0; }
int f(char k, int j) {
for (;;) {
for (; k <= 3; k++) {
*b = &c[k];
for (; d <= 1; d++)
*a = 3;
}
break;
}
}
int main() {
int i;
g();
for (i = 0; i < 4; i++)
printf("%d\n", c[i]);
}
%
Compiler explorer: https://godbolt.org/z/dTa1dvKfT
[Bug sanitizer/107410] New: ASan failed to detect a heap-buffer-overflow
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107410
Bug ID: 107410
Summary: ASan failed to detect a heap-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, `gcc-fsanitize=address -O0` reported nothing, while
`gcc -fsanitize=address -Ox` (x=1, 2, 3, or s) reported the
heap-buffer-overflow. There is a stack-buffer-overflow in `c[i] = 2`, which has
crossed the red-zone but I believe it should not affect the
heap-buffer-overflow detection.
% gcc-tk -tv
Using built-in specs.
COLLECT_GCC=gcc-tk
COLLECT_LTO_WRAPPER=/zdata/shaoli/compilers/ccbuilder-compilers/gcc-99da523359e933385484eb3b8f854a98f1b4/libexec/gcc/x86_64-pc-linux-gnu/13.0.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: ../configure --disable-multilib --disable-bootstrap
--enable-languages=c,c++
--prefix=/zdata/shaoli/compilers/ccbuilder-compilers/gcc-99da523359e933385484eb3b8f854a98f1b4
Thread model: posix
Supported LTO compression algorithms: zlib
gcc version 13.0.0 20221013 (experimental) (GCC)
%
% gcc-tk -fsanitize=address -w -g -O0 a.c && ./a.out
%
% gcc-tk -fsanitize=address -w -g -O3 a.c && ./a.out
=
==1764559==ERROR: AddressSanitizer: heap-buffer-overflow on address
0x60200038 at pc 0x00401210 bp 0x7fff57c272c0 sp 0x7fff57c272b8
WRITE of size 4 at 0x60200038 thread T0
#0 0x40120f in main
/zdata/shaoli/ubfuzz/synthesizer/bugs/gcc_work114/a.c:17
#1 0x7f5e7a12a082 in __libc_start_main
(/lib/x86_64-linux-gnu/libc.so.6+0x24082) (BuildId:
1878e6b475720c7c51969e69ab2d276fae6d1dee)
#2 0x4012bd in _start
(/zdata/shaoli/ubfuzz/synthesizer/bugs/gcc_work114/a.out+0x4012bd)
0x60200038 is located 32 bytes to the right of 8-byte region
[0x60200010,0x60200018)
allocated by thread T0 here:
#0 0x7f5e7a3c78bf in __interceptor_malloc
../../../../gcc/libsanitizer/asan/asan_malloc_linux.cpp:69
#1 0x40115f in main
/zdata/shaoli/ubfuzz/synthesizer/bugs/gcc_work114/a.c:12
SUMMARY: AddressSanitizer: heap-buffer-overflow
/zdata/shaoli/ubfuzz/synthesizer/bugs/gcc_work114/a.c:17 in main
Shadow bytes around the buggy address:
0x0c047fff7fb0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x0c047fff7fc0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x0c047fff7fd0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x0c047fff7fe0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x0c047fff7ff0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
=>0x0c047fff8000: fa fa 00 fa fa fa fa[fa]fa fa fa fa fa fa fa fa
0x0c047fff8010: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
0x0c047fff8020: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
0x0c047fff8030: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
0x0c047fff8040: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
0x0c047fff8050: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
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
==1764559==ABORTING
%
% cat a.c
typedef struct {
int a
} b;
int d;
int main() {
for (; d != 3; ++d) {
char c[2];
char e[5];
char *h = e;
int *g = malloc(2*sizeof(int));
int i=19;
b k;
c[i] = 2;
k.a = 0;
g[c[i]] = 1;
}
}
%
[Bug sanitizer/107410] ASan failed to detect a heap-buffer-overflow
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107410 --- Comment #1 from Li Shaohua --- Compiler explorer: https://godbolt.org/z/9aqvx71xo
[Bug sanitizer/107431] New: UBSan has inconsistent behaviors in certain code snippet
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107431
Bug ID: 107431
Summary: UBSan has inconsistent behaviors in certain code
snippet
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, there is a misaligned load at line 5 `long d = *c`.
UBSan detected it successfully. However, if you change the definition of `a`
from `long a` to `int a`, UBSan would report nothing.
% cat example1.c
int main() {
long a=2;
int b=1;
long *c = &b;
long d = *c;
&a;
}
% gcc -O0 -fsanitize=undefined example1.c && ./a.out
example1.c:5:10: runtime error: load of misaligned address 0x7fffd97a993c for
type 'long int', which requires 8 byte alignment
0x7fffd97a993c: note: pointer points here
f0 71 77 cc 01 00 00 00 02 00 00 00 00 00 00 00 3c 99 7a d9 ff 7f 00 00 50
9a 7a d9 ff 7f 00 00
%
% cat example2.c
int main() {
int a=2;
int b=1;
long *c = &b;
long d = *c;
&a;
}
% gcc -O0 -fsanitize=undefined example1.c && ./a.out
%
Compiler explorer: https://godbolt.org/z/4oKaMjbee
[Bug sanitizer/107431] UBSan has inconsistent behaviors in certain code snippet
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107431 --- Comment #2 from Li Shaohua --- Thanks a lot for the prompt reply!
[Bug c/107493] New: Wrong code at -Os on x86_64-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107493
Bug ID: 107493
Summary: Wrong code at -Os on x86_64-linux-gnu
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: shaohua.li at inf dot ethz.ch
Target Milestone: ---
% gcc-tk -v
Using built-in specs.
COLLECT_GCC=gcc-tk
COLLECT_LTO_WRAPPER=/zdata/shaoli/compilers/ccbuilder-compilers/gcc-db55f1dda2692c3f778ae783bc7121891c79aec4/libexec/gcc/x86_64-pc-linux-gnu/13.0.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: ../configure --disable-multilib --disable-bootstrap
--enable-languages=c,c++
--prefix=/zdata/shaoli/compilers/ccbuilder-compilers/gcc-db55f1dda2692c3f778ae783bc7121891c79aec4
Thread model: posix
Supported LTO compression algorithms: zlib
gcc version 13.0.0 20221031 (experimental) (GCC)
%
% gcc-tk -O0 a.c && ./a.out
65525
% gcc-tk -Os a.c && ./a.out
65515
%
% cat a.c
int printf(const char *format, ...);
int a;
int b(int c) {
return c;
}
int main() {
a = -21;
for (; a <= 0; a = (unsigned short)(b(a + 2) + 8))
;
printf("%d\n", a);
}
%
Compiler explorer: https://godbolt.org/z/hhqrv7hWh
[Bug sanitizer/106558] ASan failed to detect a global-buffer-overflow
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106558 --- Comment #14 from Li Shaohua --- Hello, is this patch going to be pushed to the trunk?
[Bug sanitizer/107586] New: gcc trunk missed a stack-buffer-overflow
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107586
Bug ID: 107586
Summary: gcc trunk 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, `gcc-tk -fsanitize=address -O2` successfully detected
the buffer-overflow in `memcpy()`. However, I found that when you uncomment the
line `int *f = &e[0]`, the ASAN warning went away.
I checked gcc-9, which detected the error in both cases but not for gcc-10 and
above.
I wonder if this is due to some optimizations going on that change the memory
layout, which disables ASAN's detection in this case.
Compiler explorer: https://godbolt.org/z/zfGv5378a
% cat a.c
struct a
{
int x;
};
void h(struct a *b)
{
struct a c[70];
int i;
for (i = 0; i < 70; i++)
c[i].x = 1;
__builtin_memcpy(b, c, 70*sizeof(struct a));
__builtin_printf("%d\n", b->x);
};
void g()
{
struct a * d = (struct a *)__builtin_alloca(69*sizeof(struct a));
int e[20] ;
// int *f = &e[0];
h(d);
}
int main()
{
g();
return 0;
}
%
[Bug sanitizer/107619] New: False positive of -fsanitize=null
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107619
Bug ID: 107619
Summary: False positive of -fsanitize=null
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: ---
`gcc-tk -O0 -fsanitize=null` reports a null pointer dereference in `c[0] = *a`,
which I think should not although there is a buffer-overflow in the memcpy.
Interestingly, if you uncomment `int* e[1]`, no error will be warned and the
program exits normally.
Compiler explorer: https://godbolt.org/z/bKhnKhe7d
% gcc-tk -O0 -fsanitize=null a.c && ./a.out
a.c:11:12: runtime error: load of null pointer of type 'int'
Segmentation fault
%
% cat a.c
int main() {
int* a;
// int* e[1];
int b[1];
int c[3];
a = b;
for (int i = 0; i < 3; i++) {
c[i] = 0;
}
__builtin_memcpy(a, c, 3 * sizeof(int));
c[0] = *a;
return 0;
}
%
[Bug sanitizer/107696] New: GCC trunk misses a stack-buffer-overflow
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107696
Bug ID: 107696
Summary: GCC trunk misses 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, `gcc-trunk -O0 -fsanitize=address` misses the
stack-buffer-overflow, while `gcc-trunk -Ox -fsanitize=address` (x=1,2,3, or s)
can detect it.
clang can detect it at all optimization levels.
gcc-8 can detect it at all optimization levels.
Compiler explorer: https://godbolt.org/z/z18Kzhxq5
% cat a.c
int main() {
int i;
int a[1];
for (; i < 1;){
i = 2;
a[i] = 1;
}
__builtin_printf("%d\n", a[i]);
}
%
% gcc-tk -O0 -fsanitize=address a.c &&./a.out
0
% gcc-tk -O3 -fsanitize=address a.c &&./a.out
=
==1940238==ERROR: AddressSanitizer: stack-buffer-overflow on address
0x7f9590400028 at pc 0x00401147 bp 0x7fff56ba4240 sp 0x7fff56ba4238
READ of size 4 at 0x7f9590400028 thread T0
#0 0x401146 in main
/zdata/shaoli/sanitizertesting/mutate/synthesizer/bugs/gcc_work1_0/a.c:8
#1 0x7f9592de7082 in __libc_start_main
(/lib/x86_64-linux-gnu/libc.so.6+0x24082) (BuildId:
1878e6b475720c7c51969e69ab2d276fae6d1dee)
#2 0x4011dd in _start
(/zdata/shaoli/sanitizertesting/mutate/synthesizer/bugs/gcc_work1_0/a.out+0x4011dd)
Address 0x7f9590400028 is located in stack of thread T0 at offset 40 in frame
#0 0x4010bf in main
/zdata/shaoli/sanitizertesting/mutate/synthesizer/bugs/gcc_work1_0/a.c:1
This frame has 1 object(s):
[32, 36) 'a' (line 3) <== Memory access at offset 40 overflows 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
/zdata/shaoli/sanitizertesting/mutate/synthesizer/bugs/gcc_work1_0/a.c:8 in
main
Shadow bytes around the buggy address:
0x0ff332077fb0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x0ff332077fc0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x0ff332077fd0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x0ff332077fe0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x0ff332077ff0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
=>0x0ff332078000: f1 f1 f1 f1 04[f3]f3 f3 00 00 00 00 00 00 00 00
0x0ff332078010: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x0ff332078020: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x0ff332078030: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x0ff332078040: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x0ff332078050: 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
==1940238==ABORTING
%
% gcc-tk -v
Using built-in specs.
COLLECT_GCC=gcc-tk
COLLECT_LTO_WRAPPER=/zdata/shaoli/compilers/ccbuilder-compilers/gcc-7ca912b46e0eb45ebefeb0eda4c28afe1513d272/libexec/gcc/x86_64-pc-linux-gnu/13.0.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: ../configure --disable-multilib --disable-bootstrap
--enable-languages=c,c++
--prefix=/zdata/shaoli/compilers/ccbuilder-compilers/gcc-7ca912b46e0eb45ebefeb0eda4c28afe1513d272
Thread model: posix
Supported LTO compression algorithms: zlib
gcc version 13.0.0 20221108 (experimental) (GCC)
%
[Bug sanitizer/107696] GCC trunk misses a stack-buffer-overflow
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107696
--- Comment #2 from Li Shaohua ---
(In reply to Martin Liška from comment #1)
> > int i;
> > int a[1];
> > for (; i < 1;){
>
> This depends on the uninitialized value of 'i', which is:
>
> (gdb) p i
> $1 = 32767
>
> if I run it with -O0 on my local machine. You can try
> -ftrivial-auto-var-init=zero.
Sorry, I over-reduced the test, for the following new test, I can still observe
the inconsistent results across optimization levels:
Compiler explorer: https://godbolt.org/z/b7x9zx5Ej
% cat a.c
int main() {
int b[2];
int a[1];
int i;
for (i=0; i < 1; i++)
i = i + 3;
a[i] = 1;
}
%
[Bug sanitizer/107696] GCC trunk misses a stack-buffer-overflow
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107696 --- Comment #4 from Li Shaohua --- Thanks for the prompt reply.
[Bug sanitizer/107698] New: ASAN misses a global-buffer-overflow
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107698
Bug ID: 107698
Summary: ASAN misses a global-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, `gcc-trunk -O1 -fsanitize=address` misses the
global-buffer-overflow, while `gcc-trunk -Ox -fsanitize=address` (x=0,2,3, or
s) can detect it.
clang can detect it at all optimization levels.
Compiler explorer: https://godbolt.org/z/5Tcjrc4zf
% cat a.c
int a=0, d=1;
int *b = &a, *c = &a;
int main() {
*b = 0;
b = b + 1;
*c = 1;
*b = d;
}
%
% gcc-tk -O1 -fsanitize=address a.c && ./a.out
%
% gcc-tk -O3 -fsanitize=address a.c && ./a.out
=
==851733==ERROR: AddressSanitizer: global-buffer-overflow on address
0x00404284 at pc 0x00401130 bp 0x7ffd4cb2a6a0 sp 0x7ffd4cb2a698
WRITE of size 4 at 0x00404284 thread T0
#0 0x40112f in main
/zdata/shaoli/sanitizertesting/mutate/synthesizer/bugs/work119_1/a.c:7
#1 0x7fb79dc33082 in __libc_start_main
(/lib/x86_64-linux-gnu/libc.so.6+0x24082) (BuildId:
1878e6b475720c7c51969e69ab2d276fae6d1dee)
#2 0x40119d in _start
(/zdata/shaoli/sanitizertesting/mutate/synthesizer/bugs/work119_1/a.out+0x40119d)
0x00404284 is located 0 bytes to the right of global variable 'a' defined
in 'a.c:1:5' (0x404280) of size 4
SUMMARY: AddressSanitizer: global-buffer-overflow
/zdata/shaoli/sanitizertesting/mutate/synthesizer/bugs/work119_1/a.c:7 in main
Shadow bytes around the buggy address:
0x80078800: 00 00 00 00 00 00 00 00 00 00 00 00 00 f9 f9 f9
0x80078810: f9 f9 f9 f9 00 f9 f9 f9 f9 f9 f9 f9 04 f9 f9 f9
0x80078820: f9 f9 f9 f9 00 00 00 00 00 00 00 00 f9 f9 f9 f9
0x80078830: f9 f9 f9 f9 f9 f9 f9 f9 f9 f9 f9 f9 f9 f9 f9 f9
0x80078840: f9 f9 f9 f9 f9 f9 f9 f9 f9 f9 f9 f9 00 00 00 00
=>0x80078850:[04]f9 f9 f9 f9 f9 f9 f9 00 00 00 00 00 00 00 00
0x80078860: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x80078870: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x80078880: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x80078890: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x800788a0: 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
==851733==ABORTING
%
[Bug sanitizer/107698] ASAN misses a global-buffer-overflow
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107698
--- Comment #2 from Li Shaohua ---
I found a new test where gcc-O1 misses the global-buffer-overflow. Not sure if
these two have the same root cause:
% cat a.c
int a, c;
int *b = &a;
int main() {
int d = *b;
for (; c < 3; c++)
b = b + (d == *b);
}
%
% gcc-tk -O1 -fsanitize=address a.c && ./a.out
%
% gcc-tk -O3 -fsanitize=address a.c && ./a.out
=
==3536571==ERROR: AddressSanitizer: global-buffer-overflow on address
0x00404204 at pc 0x00401130 bp 0x7ffe232ffd40 sp 0x7ffe232ffd38
...
%
[Bug sanitizer/107746] New: gcc -O1 misses a stack-buffer-overflow
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107746
Bug ID: 107746
Summary: gcc -O1 misses 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, `gcc-trunk -O1 -fsanitize=address` misses the
stack-buffer-overflow, while `gcc-trunk -Ox -fsanitize=address` (x=0,2,3, or s)
can detect it.
Maybe fundamentally similar to
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107698 but that was a miss of
global-buffer-overflow.
Compiler explorer: https://godbolt.org/z/PxWs76fqf
% cat a.c
int a;
short b;
short *c = &b;
int *d = &a;
void main() {
int e;
*d = 0;
d = &e + 3;
*d = --*c;
}
% gcc-tk -O1 -fsanitize=address a.c && ./a.out
%
% gcc-tk -O3 -fsanitize=address a.c && ./a.out
=
==1==ERROR: AddressSanitizer: stack-buffer-overflow on address 0x7f07432c
at pc 0x004011b1 bp 0x7fffa6d6a4d0 sp 0x7fffa6d6a4c8
WRITE of size 4 at 0x7f07432c thread T0
#0 0x4011b0 in main /app/example.c:9
#1 0x7f0745a17082 in __libc_start_main
(/lib/x86_64-linux-gnu/libc.so.6+0x24082) (BuildId:
1878e6b475720c7c51969e69ab2d276fae6d1dee)
#2 0x40125d in _start (/app/output.s+0x40125d) (BuildId:
c0151d5ad34e416e89a8cfe01d6f2ea794b64dec)
Address 0x7f07432c is located in stack of thread T0 at offset 44 in frame
#0 0x4010bf in main /app/example.c:5
This frame has 1 object(s):
[32, 36) 'e' (line 6) <== Memory access at offset 44 overflows 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 /app/example.c:9 in main
Shadow bytes around the buggy address:
0x7f0742fffd80: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x7f0742fffe00: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x7f0742fffe80: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x7f074200: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x7f074280: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
=>0x7f074300: f1 f1 f1 f1 04[f3]f3 f3 00 00 00 00 00 00 00 00
0x7f074380: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x7f0743000100: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x7f0743000180: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x7f0743000200: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x7f0743000280: 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/107747] New: gcc trunk at -Os misses a global-buffer-overflow
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107747
Bug ID: 107747
Summary: gcc trunk at -Os misses a global-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, `gcc-trunk -Os -fsanitize=address` misses the
global-buffer-overflow, while `gcc-trunk -Ox -fsanitize=address` (x=0,1, 2, 3)
can detect it.
gcc-12 can detect the global-buffer-overflow at all optimization levels.
clang-tk can also detect it at all optimization levels.
Compiler explorer: https://godbolt.org/z/j6vh4hhaq
% cat a.c
int a, e = 2;
long b;
int *c = &a;
char *d;
void main() {
*c = 0;
c = c + 1;
if (*c = e || (*d = 0))
for (; b;)
;
}
%
% gcc-tk -Os -fsanitize=address a.c && ./a.out
%
% gcc-tk -O3 -fsanitize=address a.c && ./a.out
=
==1==ERROR: AddressSanitizer: global-buffer-overflow on address 0x00404344
at pc 0x00401159 bp 0x7fff230c86c0 sp 0x7fff230c86b8
WRITE of size 4 at 0x00404344 thread T0
#0 0x401158 in main /app/example.c:8
#1 0x7fe78f129082 in __libc_start_main
(/lib/x86_64-linux-gnu/libc.so.6+0x24082) (BuildId:
1878e6b475720c7c51969e69ab2d276fae6d1dee)
#2 0x4011cd in _start (/app/output.s+0x4011cd) (BuildId:
864a1d27e04c540136a2c693324ee073ba4b3fa0)
0x00404344 is located 0 bytes after global variable 'a' defined in
'/app/example.c' (0x404340) of size 4
SUMMARY: AddressSanitizer: global-buffer-overflow /app/example.c:8 in main
Shadow bytes around the buggy address:
0x00404080: 00 f9 f9 f9 f9 f9 f9 f9 04 f9 f9 f9 f9 f9 f9 f9
0x00404100: 00 00 00 00 00 00 00 00 00 00 00 00 f9 f9 f9 f9
0x00404180: f9 f9 f9 f9 f9 f9 f9 f9 f9 f9 f9 f9 f9 f9 f9 f9
0x00404200: f9 f9 f9 f9 f9 f9 f9 f9 f9 f9 f9 f9 f9 f9 f9 f9
0x00404280: f9 f9 f9 f9 00 00 00 00 00 f9 f9 f9 f9 f9 f9 f9
=>0x00404300: 00 f9 f9 f9 f9 f9 f9 f9[04]f9 f9 f9 f9 f9 f9 f9
0x00404380: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x00404400: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x00404480: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x00404500: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x00404580: 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/107752] New: Lack of offset information in AddressSanitizer reports
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107752
Bug ID: 107752
Summary: Lack of offset information in AddressSanitizer reports
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,
I found that GCC's ASAN reports do not include offset information, while
Clang's ASAN does. Both GCC's UBSan and Clang'UBSan include offset information.
For example, for the following code,
% cat a.c
int main() {
int a[1] = {0};
return a[1];
}
%
GCC's ASAN report only includes the line numbers of the stack trace (a.c:3):
```
=
==1842608==ERROR: AddressSanitizer: stack-buffer-overflow on address
0x7fff7181ea14 at pc 0x55f5214542e2 bp 0x7fff7181e9e0 sp 0x7fff7181e9d0
READ of size 4 at 0x7fff7181ea14 thread T0
#0 0x55f5214542e1 in main /home/shaoli/tmp/a.c:3
...
```
Clang's ASAN report includes both the line numbers and offsets of the stack
trace (a.c:3:10):
```
=
==1910102==ERROR: AddressSanitizer: stack-buffer-overflow on address
0x7ffd53e4fa64 at pc 0x55a977f71884 bp 0x7ffd53e4fa30 sp 0x7ffd53e4fa28
READ of size 4 at 0x7ffd53e4fa64 thread T0
#0 0x55a977f71883 in main /home/shaoli/tmp/a.c:3:10
```
Both GCC's and Clang's UBsans include all information:
```
a.c:3:11: runtime error: index 1 out of bounds for type 'int [1]'
a.c:3:11: runtime error: load of address 0x7ffd420a6538 with insufficient space
for an object of type 'int'
```
I believe it would be nice to include the offset information as it is very
useful for users to quickly locate bugs in their code.
[Bug sanitizer/107752] Lack of column information in AddressSanitizer reports
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107752 --- Comment #3 from Li Shaohua --- (In reply to Andrew Pinski from comment #1) > Do you mean the column information rather than offset? Yes, I meant the column information. I don’t know the implementation details of ASAN. But as UBsan can include the column information, I presume it’s also doable in ASAN?
[Bug sanitizer/107806] New: gcc trunk at -O3 misses a global-buffer-overflow
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107806
Bug ID: 107806
Summary: gcc trunk at -O3 misses a global-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, `gcc-trunk -O3 -fsanitize=address` misses the
global-buffer-overflow, while `gcc-trunk -Ox -fsanitize=address` (x=0,1, 2, s)
can detect it.
gcc-12/11/10/9 have the same issue at -O3.
clang-tk can also detect it at all optimization levels.
Compiler explorer: https://godbolt.org/z/foeGGovdK
% cat a.c
int a;
long b;
int *c;
int e[9];
int **d = &c;
int main() {
b = 0;
for (; b < 3; b++) {
a = a + 3;
*d = &e[a];
*c = 3;
}
}
%
% gcc-tk -O3 -g -fsanitize=address a.c && ./a.out
%
% gcc-tk -O2 -g -fsanitize=address a.c && ./a.out
=
==139599==ERROR: AddressSanitizer: global-buffer-overflow on address
0x004042a4 at pc 0x0040113f bp 0x7ffedad1aeb0 sp 0x7ffedad1aea8
WRITE of size 4 at 0x004042a4 thread T0
#0 0x40113e in main
/zdata/shaoli/sanitizertesting/mutate/synthesizer/bugs/gcc/a.c:11
#1 0x7fad0bd57082 in __libc_start_main
(/lib/x86_64-linux-gnu/libc.so.6+0x24082) (BuildId:
1878e6b475720c7c51969e69ab2d276fae6d1dee)
#2 0x40119d in _start
(/zdata/shaoli/sanitizertesting/mutate/synthesizer/bugs/gcc/a.out+0x40119d)
0x004042a4 is located 60 bytes to the left of global variable 'c' defined
in 'a.c:3:6' (0x4042e0) of size 8
0x004042a4 is located 0 bytes to the right of global variable 'e' defined
in 'a.c:4:5' (0x404280) of size 36
SUMMARY: AddressSanitizer: global-buffer-overflow
/zdata/shaoli/sanitizertesting/mutate/synthesizer/bugs/gcc/a.c:11 in main
Shadow bytes around the buggy address:
0x80078800: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x80078810: 00 f9 f9 f9 f9 f9 f9 f9 00 00 00 00 00 00 00 00
0x80078820: 00 00 00 00 f9 f9 f9 f9 f9 f9 f9 f9 f9 f9 f9 f9
0x80078830: f9 f9 f9 f9 f9 f9 f9 f9 f9 f9 f9 f9 f9 f9 f9 f9
0x80078840: f9 f9 f9 f9 f9 f9 f9 f9 f9 f9 f9 f9 00 00 00 00
=>0x80078850: 00 00 00 00[04]f9 f9 f9 f9 f9 f9 f9 00 f9 f9 f9
0x80078860: f9 f9 f9 f9 00 f9 f9 f9 f9 f9 f9 f9 04 f9 f9 f9
0x80078870: f9 f9 f9 f9 00 00 00 00 00 00 00 00 00 00 00 00
0x80078880: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x80078890: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x800788a0: 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
==139599==ABORTING
%
[Bug sanitizer/107866] New: gcc trunk's UBSan misses a Nll-pointer-dereference at -O3.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107866
Bug ID: 107866
Summary: gcc trunk's UBSan misses a Nll-pointer-dereference at
-O3.
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, `gcc-trunk -O3 -fsanitize=undefined` misses the
NULL-pointer-dereference, while `gcc-trunk -Ox -fsanitize=address` (x=0,1, 2,
s) can detect it.
gcc-12 has the same issue.
gcc-11 can detect the bug at all optimization levels.
clang can also detect it at all optimization levels.
Compiler explorer: https://godbolt.org/z/WhrzP6zdf
% cat a.c
int *a;
void main() {
for (;;) {
a = 0;
if (*a)
break;
}
}
%
% gcc-tk -O3 -fsanitize=undefined -fno-sanitize-recover=all a.c &&./a.out
Segmentation fault
% gcc-tk -O2 -fsanitize=undefined -fno-sanitize-recover=all a.c &&./a.out
a.c:5:9: runtime error: load of null pointer of type 'int'
%
[Bug sanitizer/107866] [12/13 Regression] gcc trunk's UBSan misses a Null-pointer-dereference at -O3.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107866 --- Comment #2 from Li Shaohua --- (In reply to Jakub Jelinek from comment #1) > This isn't reported since r12-3918-g5b8b1522e04adc20980f396571be1929a32d148a > I wonder what is the point of -O3 -fsanitize=undefined, -fsanitize= severely > slows down the code for instrumentation and at the same time you ask for as > many optimizations as possible. I understand that optimization could optimize away UBs in a program. However, in this case, if you check the assembly code, the NULL pointer is still there and UBSAN is called to check it. So I believe this is a sanitizer issue. Many fuzzing tools these days are still using -O3 -fsanitize=xxx to compile programs for fast execution speed. So I believe no matter that optimization lever is used, as long as the UB is not optimized away, sanitizers should warn properly.
[Bug sanitizer/107893] New: gcc trunk at -O0 (UBSan) misses a Null-pointer-dereference
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107893
Bug ID: 107893
Summary: gcc trunk at -O0 (UBSan) misses a
Null-pointer-dereference
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, `gcc-trunk -O0 -fsanitize=undefined
-fno-sanitize-recover=all` misses the NULL-pointer-dereference, while
`gcc-trunk -Ox -fsanitize=address -fno-sanitize-recover=all` (x=1, 2, 3, or s)
can detect it.
I checked gcc8/9/10/11/12 and they all have this issue.
clang can detect it at all optimization levels.
Compiler explorer: https://godbolt.org/z/85qfdccse
% cat a.c
int main() {
int *a = 0;
(a[1] | a[0]) >> 056;
}
%
% gcc-tk -O0 -fsanitize=undefined -fno-sanitize-recover=all -w a.c &&./a.out
Segmentation fault
% gcc-tk -O1 -fsanitize=undefined -fno-sanitize-recover=all -w a.c &&./a.out
a.c:3:13: runtime error: load of null pointer of type 'int'
%
[Bug sanitizer/107893] gcc trunk at -O0 (UBSan) misses a Null-pointer-dereference
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107893
--- Comment #4 from Li Shaohua ---
(In reply to Richard Biener from comment #3)
> That is,
>
> int main() {
> int *a = 0;
>(a[0] | a[1]) >> 056;
> }
>
> works at -O0:
>
> t.c:3:6: runtime error: load of null pointer of type 'int'
Yes, the a[1] access caused the segfault. For clang's UBsan, it emits an error
message for a[1]:
a.c:3:5: runtime error: applying non-zero offset 4 to null pointer
SUMMARY: UndefinedBehaviorSanitizer: undefined-behavior a.c:3:5 in
Is there a way for gcc's UBsan to warn such errors?
[Bug sanitizer/107908] New: A null pointer dereference bug was missed by UBsan at -O0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107908
Bug ID: 107908
Summary: A null pointer dereference bug was missed by UBsan at
-O0
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: ---
`gcc-trunk -O0 -fsanitize=undefined -fno-sanitize-recover=all` misses the
NULL-pointer-dereference, while `gcc-trunk -Ox -fsanitize=address
-fno-sanitize-recover=all` (x=1, 2, 3, or s) can detect it.
Compiler explorer: https://godbolt.org/z/x7jo7eYYh
% cat a.c
int a;
int main() {
int *c;
for (int d = 0; d < 1; d++)
*c == (a = 0);
__builtin_printf("%d\n", *c);
}
%
% gcc-tk -O0 -fsanitize=undefined -fno-sanitize-recover=all a.c &&./a.out
1
% gcc-tk -O1 -fsanitize=undefined -fno-sanitize-recover=all -w a.c &&./a.out
a.c:5:5: runtime error: load of null pointer of type 'int'
% gcc-tk -O3 -fsanitize=undefined -fno-sanitize-recover=all -w a.c &&./a.out
a.c:5:5: runtime error: load of null pointer of type 'int'
%
[Bug sanitizer/107912] New: UBsan at -O0 missed a signed integer overflow
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107912
Bug ID: 107912
Summary: UBsan at -O0 missed a signed integer 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: ---
`gcc-trunk -O0 -fsanitize=undefined -fno-sanitize-recover=all` misses the
signed integer overflow, while `gcc-trunk -Ox -fsanitize=address
-fno-sanitize-recover=all` (x=1, 2, 3, or s) can detect it.
Compiler explorer: https://godbolt.org/z/n8qs3z6v4
% cat a.c
unsigned short a;
int b;
int main() {
int c = b = -2147483648;
a = (c && 0 == c) - b;
__builtin_printf("%d\n", a);
}
%
% gcc-tk -O0 -fsanitize=undefined -fno-sanitize-recover=all a.c &&./a.out
0
% gcc-tk -O1 -fsanitize=undefined -fno-sanitize-recover=all -w a.c &&./a.out
a.c:5:21: runtime error: negation of -2147483648 cannot be represented in type
'int'; cast to an unsigned type to negate this value to itself
% gcc-tk -O3 -fsanitize=undefined -fno-sanitize-recover=all -w a.c &&./a.out
a.c:5:21: runtime error: negation of -2147483648 cannot be represented in type
'int'; cast to an unsigned type to negate this value to itself
%
[Bug sanitizer/108014] New: Incorrect line number in UBSAN's report
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108014
Bug ID: 108014
Summary: Incorrect line number in UBSAN's report
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, GCC's UBsan at -O1 and above produces incorrect line
number in the final report.
Compiler explorer: https://godbolt.org/z/jvvdrfPdo
% cat -n a.c
1 int a, b;
2 char c[5];
3 int d[1];
4 static int g() {
5long e;
6b = __INT_MAX__;
7for (int f = 0; f < sizeof(c); f++)
8 e = b + 1;
9return 0;
10 }
11 int main() {
12for (b = 0;b<1; b++) {
13 d[a];
14 g();
15}
16 }
%
% gcc-tk -O0 -fsanitize=undefined -fno-sanitize-recover=all a.c && ./a.out
a.c:8:11: runtime error: signed integer overflow: 2147483647 + 1 cannot be
represented in type 'int'
% gcc-tk -O1 -fsanitize=undefined -fno-sanitize-recover=all a.c && ./a.out
a.c:12:20: runtime error: signed integer overflow: 2147483647 + 1 cannot be
represented in type 'int'
%
[Bug sanitizer/108023] New: Incorrect line number in ASAN's report
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108023
Bug ID: 108023
Summary: Incorrect line number in ASAN's report
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, GCC's ASAN at -O1 and above produce incorrect line
numbers in the final reports (Line 15 v.s. Line 8).
Compiler explorer: https://godbolt.org/z/4953EPr78
% cat a.c
int a, b, c, g, f;
static long d(int);
long d(int h) {
int **j = (int**)malloc(sizeof(int *) * sizeof(int));
for (int i = 0; i < sizeof(int); i++)
j[i] = malloc(sizeof(f));
int *k = malloc(sizeof(int) * sizeof(g));
for (h=0; h <= 2; h++) {
free(k);
for (b=0; b <= 2; b++)
k[3] = j[0][h];
}
return k[a];
}
void e() {
c = d(0);
}
int main() {
e();
return c;
}
%
% gcc-tk -O0 -fsanitize=address -w -g a.c && ./a.out
=
==3175968==ERROR: AddressSanitizer: heap-use-after-free on address
0x6020009c at pc 0x0040130f bp 0x7ffd47fc9fd0 sp 0x7ffd47fc9fc8
WRITE of size 4 at 0x6020009c thread T0
#0 0x40130e in d /a.c:15
#1 0x4013a3 in e /a.c:21
#2 0x4013ba in main /a.c:25
...
%
% gcc-tk -O2 -fsanitize=address -w -g a.c && ./a.out
==3254785==ERROR: AddressSanitizer: heap-use-after-free on address
0x6020009c at pc 0x00401354 bp 0x7ffce8fa2e80 sp 0x7ffce8fa2e78
WRITE of size 4 at 0x6020009c thread T0
#0 0x401353 in d /a.c:8
#1 0x4010e8 in e /a.c:21
#2 0x4010e8 in main /a.c:25
...
%
[Bug sanitizer/108029] New: GCC'ASAN at -O0 failed to detect a memory leak
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108029
Bug ID: 108029
Summary: GCC'ASAN at -O0 failed to detect a memory leak
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, GCC trunk at -O0 won't report the memory leak. However,
-O1 and above can successfully report the leak. I checked the assembly code at
-O0, which indeed allocated the memory.
This issue seems to start from GCC-9, GCC-8 can detect the leak at all
optimization levels.
Clang can also detect it at -O0.
Compiler explorer: https://godbolt.org/z/vxoxxY55x
% cat a.c
short a = 1;
int main() {
int *b = malloc(sizeof(int));
for (;a<1;a++) {
int *c = &b[0];
free(b);
int d[1];
int **e = malloc(sizeof &d);
e[0] = &c;
if (a || b[0]) {
*c = 4 ^ *c;
*c = 5;
}
}
}
%
% gcc-tk -O0 -fsanitize=address a.c
% ASAN_OPTIONS=detect_leaks=1 ./a.out
%
% gcc-tk -O1 -fsanitize=address a.c
% ASAN_OPTIONS=detect_leaks=1 ./a.out
=
==2169810==ERROR: LeakSanitizer: detected memory leaks
Direct leak of 4 byte(s) in 1 object(s) allocated from:
#0 0x7fe9fc8a98bf in __interceptor_malloc
../../../../gcc/libsanitizer/asan/asan_malloc_linux.cpp:69
#1 0x401234 in main
(/zdata/shaoli/sanitizertesting_UseAfterFree/mutate/bugs/gcc/a.out+0x401234)
SUMMARY: AddressSanitizer: 4 byte(s) leaked in 1 allocation(s).
%
[Bug sanitizer/108029] GCC'ASAN at -O0 failed to detect a memory leak
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108029 --- Comment #2 from Li Shaohua --- (In reply to Martin Liška from comment #1) > I can see the leak with both gcc-12 and gcc master. Interesting, because I tested using Compiler explorer. On my local machines, some gcc-12 -O0 won't report, but some do.
[Bug sanitizer/108029] GCC'ASAN at -O0 failed to detect a memory leak
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108029 --- Comment #3 from Li Shaohua --- (In reply to Li Shaohua from comment #2) > (In reply to Martin Liška from comment #1) > > I can see the leak with both gcc-12 and gcc master. > > Interesting, because I tested using Compiler explorer. On my local machines, > some gcc-12 -O0 won't report, but some do. Specifically, gcc-12.1.1 won't report, but gcc-12.1.0 does.
[Bug sanitizer/108060] New: UBsan missed an out-of-bound bug at -O0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108060
Bug ID: 108060
Summary: UBsan missed an out-of-bound bug at -O0
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, UBsan at -O0 missed reporting the out-of-bound access,
while -O1 and above caught it.
Clang could detect it at all optimization levels.
Compiler explorer: https://godbolt.org/z/Tb9Mern7M
% cat a.c
int a[8];
short b;
char c;
int main() {
b = -32768;
a[b] |= c;
}
%
% gcc-tk -O0 -fsanitize=undefined -fno-sanitize-recover=all a.c && ./a.out
Segmentation fault
% gcc-tk -O1 -fsanitize=undefined -fno-sanitize-recover=all a.c && ./a.out
a.c:6:4: runtime error: index -32768 out of bounds for type 'int [8]'
%
Interestingly, if you don't use `-fno-sanitize-recover=all`, none of opt levels
could detect it:
% gcc-tk -O1 -fsanitize=undefined a.c && ./a.out
Segmentation fault
%
[Bug sanitizer/108085] New: gcc trunk's ASAN at -O3 missed a stack-use-after-scope
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108085
Bug ID: 108085
Summary: gcc trunk's ASAN at -O3 missed a stack-use-after-scope
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 -O3 failed to report the stack-use-after-scope,
other opt levels detected it successfully.
GCC-8 works fine.
Clang at all optimization levels reported it.
Compiler explorer: https://godbolt.org/z/jbsThYWa6
% cat a.c
int a;
void b() {
int c[1];
c;
}
int main() {
int d[1]={1};
int *e = d;
a = 0;
for (; a <= 5; ++a) {
int f[1]={};
e = f;
a || (b(), 1);
}
return *e;
}
%
% gcc-tk -O2 -fsanitize=address -g a.c && ./a.out
=
==780198==ERROR: AddressSanitizer: stack-use-after-scope on address
0x7f2307600030 at pc 0x004011c5 bp 0x7ffdd19ecd80 sp 0x7ffdd19ecd78
READ of size 4 at 0x7f2307600030 thread T0
#0 0x4011c4 in main /a.c:15
#1 0x7f2309f41082 in __libc_start_main
(/lib/x86_64-linux-gnu/libc.so.6+0x24082) (BuildId:
1878e6b475720c7c51969e69ab2d276fae6d1dee)
#2 0x40126d in _start (/a.out+0x40126d)
Address 0x7f2307600030 is located in stack of thread T0 at offset 48 in frame
#0 0x4010bf in main /a.c:6
This frame has 3 object(s):
[32, 36) 'd' (line 7)
[48, 52) 'f' (line 11) <== Memory access at offset 48 is inside this
variable
[64, 68) 'c' (line 3)
...
%
% gcc-tk -O3 -fsanitize=address -g a.c && ./a.out
%
[Bug sanitizer/108094] New: gcc trunk's ASAN at -O2 and above did not report a stack-use-after-return
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108094
Bug ID: 108094
Summary: gcc trunk's ASAN at -O2 and above did not report a
stack-use-after-return
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: ---
ASAN at -O0/1 reported the stack-use-after-return bug, however -O2 and above
only reported SEGV. I checked the pointer addresses and noted this may due to
over-optimization of UB behavior, i.e., variable a is optimized to NULL. Not
sure if this is an issue or not.
Clang can detect it at all optimization levels.
Compiler explorer: https://godbolt.org/z/bYPxe31Mx
% cat a.c
int *a;
int d;
int *e() {
int b[1]={0};
__builtin_printf("&b[0]=%p\n", &b[0]);
int *c = &b[0];
__builtin_printf("c=%p\n", c);
return c;
}
int main() {
a = e();
__builtin_printf("a=%p\n", a);
d = *a;
return d;
}
% gcc-tk -O0 -fsanitize=address a.c -g
% AN_OPTIONS=detect_stack_use_after_return=1 ./a.out
&b[0]=0x7fe7cc20
c=0x7fe7cc20
a=0x7fe7cc20
=
==1645405==ERROR: AddressSanitizer: stack-use-after-return on address
0x7fe7cc20 at pc 0x00401325 bp 0x7ffe8e2fe990 sp 0x7ffe8e2fe988
READ of size 4 at 0x7fe7cc20 thread T0
#0 0x401324 in main /a.c:13
#1 0x7fe7cea78082 in __libc_start_main
(/lib/x86_64-linux-gnu/libc.so.6+0x24082) (BuildId:
1878e6b475720c7c51969e69ab2d276fae6d1dee)
#2 0x4010dd in _start (/a.out+0x4010dd)
Address 0x7fe7cc20 is located in stack of thread T0 at offset 32 in frame
#0 0x4011a5 in e /a.c:3
This frame has 1 object(s):
[32, 36) 'b' (line 4) <== Memory access at offset 32 is inside this
variable
...
%
% gcc-tk -O2 -fsanitize=address a.c -g
% AN_OPTIONS=detect_stack_use_after_return=1 ./a.out
&b[0]=0x7f3f2a100020
c=0x7f3f2a100020
a=(nil)
AddressSanitizer:DEADLYSIGNAL
=
==1885716==ERROR: AddressSanitizer: SEGV on unknown address 0x (pc
0x00401107 bp 0x sp 0x7fff49942b00 T0)
==1885716==The signal is caused by a READ memory access.
==1885716==Hint: address points to the zero page.
#0 0x401107 in main /a.c:13
#1 0x7f3f2cb26082 in __libc_start_main
(/lib/x86_64-linux-gnu/libc.so.6+0x24082) (BuildId:
1878e6b475720c7c51969e69ab2d276fae6d1dee)
#2 0x40117d in _start (/a.out+0x40117d)
...
%
[Bug sanitizer/108094] gcc trunk's ASAN at -O2 and above did not report a stack-use-after-return
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108094
--- Comment #2 from Li Shaohua ---
(In reply to Martin Liška from comment #1)
> gcc pr108094.c -g -Wall -Werror -O2
> pr108094.c: In function ‘e’:
> pr108094.c:8:10: error: function returns address of local variable
> [-Werror=return-local-addr]
> 8 | return c;
> | ^
> pr108094.c:4:7: note: declared here
> 4 | int b[1]={0};
> | ^
> cc1: all warnings being treated as errors
>
> The warning is quite obvious and should not be ignored.
So there is indeed a stack-use-after-return, but gcc's ASAN just does not
report it at -O2?
[Bug sanitizer/105592] New: array out of bound not detected by ubsan
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105592
Bug ID: 105592
Summary: array out of bound not detected by ubsan
Product: gcc
Version: 12.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, I wonder why &a[1] is not considered as an out-of-bound
while &a[2] is.
$cat a1.c
a[1];
main() {
int *b = &a[1];
return *b;
}
$
$gcc -O0 -fsanitize=bounds -w a1.c && ./a.out
$
$ cat a2.c
a[1];
main() {
int *b = &a[2];
return *b;
}
$gcc -O0 -fsanitize=bounds -w a2.c && ./a.out
a2.c:3:14: runtime error: index 2 out of bounds for type 'int [1]'
$
[Bug tree-optimization/105618] New: Missed loop body simplification by -O3 (trunk v.s. 10.3)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105618
Bug ID: 105618
Summary: Missed loop body simplification by -O3 (trunk v.s.
10.3)
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: shaohua.li at inf dot ethz.ch
Target Milestone: ---
For the following code, gcc truck -O3 fails to optimize away the loop body,
while gcc10.3 can. You can see from the assembly code that gcc10.3 figured out
that the variable c would be a constant after the loop while gcc-trunk didn't.
$cat a.c
static int b=4;
int c;
int main() {
int e[5] = {1,1,1,1,1};
for (; b >= 0; b--) {
c = e[b];
}
return 0;
}
$
$gcc-trunk -O3 -S -o trunk.s a.c
$gcc-10-3 -O3 -S -o 10-3.s a.c
$wc trunk.s 10-3.s
66 147 1005 trunk.s
52 106 698 10-3.s
118 253 1703 total
$
$cat 10-3.s
main:
.LFB0:
.cfi_startproc
endbr64
movlb(%rip), %eax
testl %eax, %eax
js .L2
movl$1, c(%rip)
movl$-1, b(%rip)
.L2:
xorl%eax, %eax
ret
$
$cat trunk.s
main:
.LFB0:
.cfi_startproc
movdqa .LC0(%rip), %xmm0
movlb(%rip), %eax
movl$1, -24(%rsp)
movaps %xmm0, -40(%rsp)
testl %eax, %eax
js .L2
movslq %eax, %rdx
leal-1(%rax), %ecx
movl-40(%rsp,%rdx,4), %edx
je .L3
leal-2(%rax), %edx
cmpl$1, %eax
je .L10
leal-3(%rax), %ecx
cmpl$2, %eax
je .L6
leal-4(%rax), %edx
cmpl$3, %eax
je .L10
.L6:
movslq %edx, %rdx
movl-40(%rsp,%rdx,4), %edx
.L3:
movl%edx, c(%rip)
movl$-1, b(%rip)
.L2:
xorl%eax, %eax
ret
.L10:
movslq %ecx, %rcx
movl-40(%rsp,%rcx,4), %edx
jmp .L3
$
[Bug sanitizer/105697] New: GCC trunk failed to detect a stack buffer-overflow
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105697
Bug ID: 105697
Summary: GCC trunk failed to detect 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, `gcc-trunk -O0 -fsanitize=address` didn't report the
buffer-overflow in e(), while `gcc-trunk -O3 -fsanitize=address` reported it
successfully.
$cat a.c
int *d;
int e(volatile int h) {
d = &h;
return *(d + 1);
}
int main() {
return e(0);
}
$
$gcc-trunk -O0 -fsanitize=address a.c && ./a.out
$
$gcc-trunk -O3 -fsanitize=address a.c && ./a.out
=
==1721824==ERROR: AddressSanitizer: stack-buffer-overflow on address
0x7ffd3c2733d4 at pc 0x55a2efd4b1f5 bp 0x7ffd3c2733a0 sp 0x7ffd3c273390
READ of size 4 at 0x7ffd3c2733d4 thread T0
#0 0x55a2efd4b1f4 in main (/project/shaoli/data/work-amd3/a.out+0x11f4)
#1 0x7f77fb01d082 in __libc_start_main
(/lib/x86_64-linux-gnu/libc.so.6+0x24082)
#2 0x55a2efd4b28d in _start (/project/shaoli/data/work-amd3/a.out+0x128d)
Address 0x7ffd3c2733d4 is located in stack of thread T0 at offset 36 in frame
#0 0x55a2efd4b10f in main (/project/shaoli/data/work-amd3/a.out+0x110f)
This frame has 1 object(s):
[32, 36) 'h' (line 6) <== Memory access at offset 36 overflows 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
(/project/shaoli/data/work-amd3/a.out+0x11f4) in main
Shadow bytes around the buggy address:
0x100027846620: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x100027846630: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x100027846640: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x100027846650: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x100027846660: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
=>0x100027846670: 00 00 00 00 00 00 f1 f1 f1 f1[04]f3 f3 f3 00 00
0x100027846680: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x100027846690: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x1000278466a0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x1000278466b0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x1000278466c0: 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
Shadow gap: cc
==1721824==ABORTING
[Bug sanitizer/105714] New: ASan in gcc trunk missed a buffer-overflow at -Os
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105714
Bug ID: 105714
Summary: ASan in gcc trunk missed a buffer-overflow at -Os
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, `gcc-trunk -Os -fsanitize=address` reported nothing,
however other opt levels reported the global buffer-overflow at the end of
function g().
Initially, I thought it might due to optimization at -Os, but I indeed found
the overflowed buffer be loaded in the assembly code and gcc-11 -Os did not
miss this bug: https://godbolt.org/z/r4rhM8bjz
$cat a.c
struct a {
int x
};
struct a b[2];
struct a *c = b, *d = b;
int e;
int g() {
for (e = 0; e < 1; e++) {
int i[1];
i;
}
for (int h = 0; h < 3; h++)
*c = *d;
*c = *(b+3);
return c->x;
}
void main() {
g();
}
$
$gcc-trunk -Os -fsanitize=address a.c && ./a.out
$
$gcc-trunk -O3 -fsanitize=address a.c && ./a.out
==12272==ERROR: AddressSanitizer: global-buffer-overflow on address
0x004042ac at pc 0x0040132a bp 0x7ffdbc905820 sp 0x7ffdbc905818
READ of size 4 at 0x004042ac thread T0
#0 0x401329 in g /local/home/shaoli/a.c:15
#1 0x7fc367b2f082 in __libc_start_main
(/lib/x86_64-linux-gnu/libc.so.6+0x24082) (BuildId:
1878e6b475720c7c51969e69ab2d276fae6d1dee)
#2 0x40111d in _start (/local/home/shaoli/a.out+0x40111d)
0x004042ac is located 4 bytes to the right of global variable 'b' defined
in 'a.c:4:10' (0x4042a0) of size 8
SUMMARY: AddressSanitizer: global-buffer-overflow /local/home/shaoli/a.c:15 in
g
Shadow bytes around the buggy address:
0x80078800: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x80078810: 00 f9 f9 f9 f9 f9 f9 f9 00 f9 f9 f9 f9 f9 f9 f9
0x80078820: 00 00 00 00 00 00 00 00 f9 f9 f9 f9 f9 f9 f9 f9
0x80078830: f9 f9 f9 f9 f9 f9 f9 f9 f9 f9 f9 f9 f9 f9 f9 f9
0x80078840: f9 f9 f9 f9 f9 f9 f9 f9 00 00 00 00 04 f9 f9 f9
=>0x80078850: f9 f9 f9 f9 00[f9]f9 f9 f9 f9 f9 f9 00 00 00 00
0x80078860: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x80078870: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x80078880: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x80078890: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x800788a0: 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
==12272==ABORTING
[Bug sanitizer/105750] New: Too small red zone size for struct variables.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105750
Bug ID: 105750
Summary: Too small red zone size for struct variables.
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, gcc only generates 32 bytes red zone for the struct
variable j, which makes it fail to detect the buffer-overflow in k().
$cat a.c
struct a {
int b;
long c[2];
char d;
long f;
char g
};
int i;
volatile struct a j[1][6] = {2};
long k() {
return j[0][6].f;
}
int main() {
return k();
}
$
$gcc-trunk -O0 -fsanitize=address -w a.c && ./a.out
$
$
[Bug sanitizer/105750] Too small red zone size for struct variables.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105750
--- Comment #2 from Li Shaohua ---
Yea, I'm aware of that. What makes me confused is for the following code, gcc
generates a larger redone for the struct variable j, i.e., 48 bytes.
https://godbolt.org/z/Wv1djjrqv
$cat b.c
struct a {
long f;
};
int i;
volatile struct a j[1][6] = {2};
long k() {
return j[0][6].f;
}
int main() {
return k();
}
$
$
[Bug sanitizer/105697] GCC trunk failed to detect a stack buffer-overflow
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105697 --- Comment #2 from Li Shaohua --- I think the volatile keyword in function parameters is critical to this bug.
[Bug demangler/101798] New: rust-demangle.c infinite recursion
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101798 Bug ID: 101798 Summary: rust-demangle.c infinite recursion Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: demangler Assignee: unassigned at gcc dot gnu.org Reporter: shaohua.li at inf dot ethz.ch Target Milestone: --- Created attachment 51267 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=51267&action=edit poc Hi there, I found a stack-overflow in rust-demangle.c when fuzzing binutils. I was instructed to report this bug here by binutils's maintainers. See details below. - binutils version: 2.38(Head), commit af51804103a08cd1e12edc4f4a30eec2c5c4f9e8 - Compiler: clang12 - Platform: Ubuntu 18.04.5 LTS, x86_64 - Reproduce: run `nm-new -C poc` AddressSanitizer report: ==498==ERROR: AddressSanitizer: stack-overflow on address 0x7ffd9daa0d88 (pc 0x004967a6 bp 0x7ffd9daa15d0 sp 0x7ffd9daa0d90 T0) #0 0x4967a6 in __asan_memcpy (/out_bin/nm-new+0x4967a6) #1 0x163535e in str_buf_append /binutils_latest/repo/libiberty/./rust-demangle.c:1493:3 #2 0x1635278 in str_buf_demangle_callback /binutils_latest/repo/libiberty/./rust-demangle.c:1500:3 #3 0x1631f3b in print_str /binutils_latest/repo/libiberty/./rust-demangle.c:273:5 #4 0x163662c in demangle_type /binutils_latest/repo/libiberty/./rust-demangle.c:893:7 #5 0x1634b7f in demangle_path /binutils_latest/repo/libiberty/./rust-demangle.c:747:7 #6 0x16372f6 in demangle_type /binutils_latest/repo/libiberty/./rust-demangle.c:1031:7 ...
[Bug tree-optimization/113898] New: ICE in copy_reference_ops_from_ref, at tree-ssa-sccvn.cc:1156
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113898
Bug ID: 113898
Summary: ICE in copy_reference_ops_from_ref, at
tree-ssa-sccvn.cc:1156
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: shaohua.li at inf dot ethz.ch
CC: rguenth at gcc dot gnu.org
Target Milestone: ---
gcc at -Os crashed on the test case.
Bisected to r14-8929-g938a419182f
%cat reduced.c
int a, d;
unsigned **b;
long c, f;
long e[2][1];
void g() {
int h = 0;
for (; h < 2; h++) {
e[h][d + **b + a] = c;
if (f)
for (;;)
;
}
}
void main() {}
%
%gcc -Os reduced.c
int a, d;
unsigned **b;
long c, f;
long e[2][1];
void g() {
int h = 0;
for (; h < 2; h++) {
e[h][d + **b + a] = c;
if (f)
for (;;)
;
}
}
void main() {}
%
[Bug tree-optimization/113898] [14 regression] ICE in copy_reference_ops_from_ref, at tree-ssa-sccvn.cc:1156 since r14-8929-g938a419182f
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113898
Shaohua Li changed:
What|Removed |Added
Status|RESOLVED|REOPENED
Resolution|FIXED |---
--- Comment #5 from Shaohua Li ---
Looks like the fix is not complete
Compiler explorer: https://godbolt.org/z/z3YKznMzE
% cat reduced.c
long a, b, c;
int d;
long e[2][1];
int f() {
if (c == a)
c = b;
}
void g() {
int h, i = 0;
for (; f() + d + i; i++)
e[h][i] = 4;
}
void main() {}
%
% gcc -O3 reduced.c
during GIMPLE pass: fre
reduced.c: In function 'g':
reduced.c:8:6: internal compiler error: in copy_reference_ops_from_ref, at
tree-ssa-sccvn.cc:1177
8 | void g() {
| ^
0x233ba2c internal_error(char const*, ...)
???:0
0x96c20f fancy_abort(char const*, int, char const*)
???:0
0x12991ba vn_reference_lookup(tree_node*, tree_node*, vn_lookup_kind,
vn_reference_s**, bool, tree_node**, tree_node*, bool)
???:0
Please submit a full bug report, with preprocessed source (by using
-freport-bug).
Please include the complete backtrace with any bug report.
See
[Bug c/110753] New: ICE in meet_with_1, at ipa-cp.cc:1057
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110753
Bug ID: 110753
Summary: ICE in meet_with_1, at ipa-cp.cc:1057
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: shaohua.li at inf dot ethz.ch
Target Milestone: ---
This looks like a recent regression.
Compiler explorer: https://godbolt.org/z/sGjbfYj16
$ cat a.c
int a, b, c;
int d(long e, long f) { return f == 0 || e && f == 1 ?: f; }
int g() {}
static int h(long e) {
b = e + 4294967295;
a = d(b || d(e, 8), g());
}
int i() {
c = i;
h(c);
}
int main() {}
$
$ gcc-tk -O3 a.c
: In function 'i':
:9:5: warning: assignment to 'int' from 'int (*)()' makes integer from
pointer without a cast [-Wint-conversion]
9 | c = i;
| ^
during IPA pass: cp
: At top level:
:12:1: internal compiler error: in meet_with_1, at ipa-cp.cc:1057
12 | int main() {}
| ^~~
0x215ca2e internal_error(char const*, ...)
???:0
0x9cfbf0 fancy_abort(char const*, int, char const*)
???:0
Please submit a full bug report, with preprocessed source (by using
-freport-bug).
Please include the complete backtrace with any bug report.
See
[Bug c/110769] New: ICE in adjust_loop_info_after_peeling, at tree-ssa-loop-ivcanon.cc:1023
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110769
Bug ID: 110769
Summary: ICE in adjust_loop_info_after_peeling, at
tree-ssa-loop-ivcanon.cc:1023
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: shaohua.li at inf dot ethz.ch
Target Milestone: ---
Looks like a recent regression.
Compiler explorer: https://godbolt.org/z/eMh54dYKz
$ cat a.c
int a;
int b(unsigned d) {
int c = 0;
for (; d; c++)
d >>= 1;
return c;
}
int main() {
a = 0;
for (; b(31) + a > 21; a = a + (unsigned)8)
;
for (;;)
;
}
$
$ gcc-tk -O3 a.c
during GIMPLE pass: ch_vect
crash_0_reduced.c: In function ‘main’:
crash_0_reduced.c:8:5: internal compiler error: in
adjust_loop_info_after_peeling, at tree-ssa-loop-ivcanon.cc:1023
8 | int main() {
| ^~~~
0x216183e internal_error(char const*, ...)
???:0
0x9d1376 fancy_abort(char const*, int, char const*)
???:0
Please submit a full bug report, with preprocessed source (by using
-freport-bug).
Please include the complete backtrace with any bug report.
See
[Bug target/107257] [13 Regression] Wrong code at -O2 on x86_64-linux-gnu since r13-857-gf1652e3343b1ec47
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107257 Shaohua Li changed: What|Removed |Added Resolution|DUPLICATE |--- Status|RESOLVED|WAITING --- Comment #8 from Shaohua Li --- This bug is not a dup of https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107172, which has been fixed but the trunk is still faulty on this test case.
[Bug target/107257] [13 Regression] Wrong code at -O2 on x86_64-linux-gnu since r13-857-gf1652e3343b1ec47
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107257 Shaohua Li changed: What|Removed |Added Resolution|--- |DUPLICATE Status|WAITING |RESOLVED --- Comment #9 from Shaohua Li --- Sorry, this is indeed a dup. *** This bug has been marked as a duplicate of bug 107172 ***
[Bug target/107172] [13 Regression] wrong code with "-O1 -ftree-vrp" on x86_64-linux-gnu since r13-1268-g8c99e307b20c502e
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107172 --- Comment #52 from Shaohua Li --- *** Bug 107257 has been marked as a duplicate of this bug. ***
