public inbox for gcc-bugs@sourceware.org
help / color / mirror / Atom feed
* [Bug sanitizer/108541] New: ASAN since GCC 9 missed a stack-buffer-overflow
@ 2023-01-25 16:41 shaohua.li at inf dot ethz.ch
2023-01-26 9:24 ` [Bug sanitizer/108541] ASAN since GCC 9 missed a stack-buffer-overflow since r9-4503-g6e644a50045f8032 marxin at gcc dot gnu.org
2023-03-16 14:30 ` marxin at gcc dot gnu.org
0 siblings, 2 replies; 3+ messages in thread
From: shaohua.li at inf dot ethz.ch @ 2023-01-25 16:41 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108541
Bug ID: 108541
Summary: ASAN since GCC 9 missed a stack-buffer-overflow
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: sanitizer
Assignee: unassigned at gcc dot gnu.org
Reporter: shaohua.li at inf dot ethz.ch
CC: dodji at gcc dot gnu.org, dvyukov at gcc dot gnu.org,
jakub at gcc dot gnu.org, kcc at gcc dot gnu.org, marxin at gcc dot gnu.org
Target Milestone: ---
For the following code, ASAN at -O0 missed the stack-buffer-overflow while
other opt levels caught it. This issue happens since GCC-9. GCC-8 and before
worked fine.
I also noticed that there is an incompatible pointer assignment `i = &m`, but
anyway the bufferoverflow should be reported.
Clang can detect it at all opt levels.
Compiler explorer: https://godbolt.org/z/ovTEKG9PM
% cat a.c
struct a {
long b;
int c;
long d;
short e;
long f;
long g;
};
struct {
struct a b;
unsigned : 6;
} h, *i;
int j;
int main() {
struct a *k;
&k;
long l[3];
l[j] = 4;
int m = 1;
i = &m;
*i = h;
return m;
}
%
% gcc-tk -fsanitize=address -w -O0 a.c && ./a.out
%
% gcc-tk -fsanitize=address -w -O1 a.c && ./a.out
=================================================================
==1==ERROR: AddressSanitizer: stack-buffer-overflow on address 0x7f8605800030
at pc 0x0000004012e0 bp 0x7ffdfd9e9b10 sp 0x7ffdfd9e9b08
WRITE of size 56 at 0x7f8605800030 thread T0
#0 0x4012df in main /a.c:21
#1 0x7f860810f082 in __libc_start_main
(/lib/x86_64-linux-gnu/libc.so.6+0x24082) (BuildId:
1878e6b475720c7c51969e69ab2d276fae6d1dee)
#2 0x4010cd in _start (/a.s+0x4010cd) (BuildId:
62f9205a5d8cda9f9cd98eb2592c0ba25a6a0a20)
Address 0x7f8605800030 is located in stack of thread T0 at offset 48 in frame
#0 0x401195 in main /app/example.c:14
This frame has 2 object(s):
[48, 52) 'm' (line 19) <== Memory access at offset 48 partially overflows
this variable
[64, 88) 'l' (line 17) <== Memory access at offset 48 partially underflows
this variable
HINT: this may be a false positive if your program uses some custom stack
unwind mechanism, swapcontext or vfork
(longjmp and C++ exceptions *are* supported)
SUMMARY: AddressSanitizer: stack-buffer-overflow /a.c:21 in main
Shadow bytes around the buggy address:
...
%
^ permalink raw reply [flat|nested] 3+ messages in thread
* [Bug sanitizer/108541] ASAN since GCC 9 missed a stack-buffer-overflow since r9-4503-g6e644a50045f8032
2023-01-25 16:41 [Bug sanitizer/108541] New: ASAN since GCC 9 missed a stack-buffer-overflow shaohua.li at inf dot ethz.ch
@ 2023-01-26 9:24 ` marxin at gcc dot gnu.org
2023-03-16 14:30 ` marxin at gcc dot gnu.org
1 sibling, 0 replies; 3+ messages in thread
From: marxin at gcc dot gnu.org @ 2023-01-26 9:24 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108541
Martin Liška <marxin at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Last reconfirmed| |2023-01-26
Summary|ASAN since GCC 9 missed a |ASAN since GCC 9 missed a
|stack-buffer-overflow |stack-buffer-overflow since
| |r9-4503-g6e644a50045f8032
Assignee|unassigned at gcc dot gnu.org |marxin at gcc dot gnu.org
Ever confirmed|0 |1
Status|UNCONFIRMED |ASSIGNED
--- Comment #1 from Martin Liška <marxin at gcc dot gnu.org> ---
Good catch! Started with my r9-4503-g6e644a50045f8032.
^ permalink raw reply [flat|nested] 3+ messages in thread
* [Bug sanitizer/108541] ASAN since GCC 9 missed a stack-buffer-overflow since r9-4503-g6e644a50045f8032
2023-01-25 16:41 [Bug sanitizer/108541] New: ASAN since GCC 9 missed a stack-buffer-overflow shaohua.li at inf dot ethz.ch
2023-01-26 9:24 ` [Bug sanitizer/108541] ASAN since GCC 9 missed a stack-buffer-overflow since r9-4503-g6e644a50045f8032 marxin at gcc dot gnu.org
@ 2023-03-16 14:30 ` marxin at gcc dot gnu.org
1 sibling, 0 replies; 3+ messages in thread
From: marxin at gcc dot gnu.org @ 2023-03-16 14:30 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108541
Martin Liška <marxin at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|ASSIGNED |RESOLVED
Resolution|--- |WONTFIX
--- Comment #2 from Martin Liška <marxin at gcc dot gnu.org> ---
Ok, I've got a reduced test-case:
cat pr108541.c
struct S {
// WORKS: char padding[48];
char padding[49];
};
struct S h, *i;
int main() {
int *dummy;
&dummy;
int m = 1;
char *ptr = (char *)&m;
*(struct S *)(char *)(ptr - 0) = h;
return 0;
}
so the shadow memory looks like this:
0x7ffff5300000: f1 f1 f1 f1 f1 f1 04 f2 00 f3 f3 f3
[48, 52) 'm' (line 12)
[64, 72) 'dummy' (line 9)
what happens here: during the expansion of .ASAN_CHECK (5, ptr_5, 49, 1);
we check for the memory area beginning (that's fine), and than the ending,
which is out of the poisoned memory. It's unfortunate that the middle area of
the 49B contains a poisoned memory.
Closing as won't fix, we can't check every single byte of shadow memory, that
would be very slow.
^ permalink raw reply [flat|nested] 3+ messages in thread
end of thread, other threads:[~2023-03-16 14:30 UTC | newest]
Thread overview: 3+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2023-01-25 16:41 [Bug sanitizer/108541] New: ASAN since GCC 9 missed a stack-buffer-overflow shaohua.li at inf dot ethz.ch
2023-01-26 9:24 ` [Bug sanitizer/108541] ASAN since GCC 9 missed a stack-buffer-overflow since r9-4503-g6e644a50045f8032 marxin at gcc dot gnu.org
2023-03-16 14:30 ` marxin at gcc dot gnu.org
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).