public inbox for gcc-bugs@sourceware.org
help / color / mirror / Atom feed
* [Bug sanitizer/108903] New: ASAN may miss a global-buffer-overflow
@ 2023-02-23 12:01 shaohua.li at inf dot ethz.ch
2023-02-23 14:11 ` [Bug sanitizer/108903] " marxin at gcc dot gnu.org
0 siblings, 1 reply; 2+ messages in thread
From: shaohua.li at inf dot ethz.ch @ 2023-02-23 12:01 UTC (permalink / raw)
To: gcc-bugs
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 0x000000404244
at pc 0x00000040119a bp 0x7fff990d2e40 sp 0x7fff990d2e38
READ of size 4 at 0x000000404244 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 <bb 4>; [5.50%]
else
goto <bb 7>; [94.50%]
<bb 4> [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
movw b(%rip), %ax
pushq %rbx
xorl %ecx, %ecx
movq %rdx, %rbx
movl e(%rip), %r11d
...
^ permalink raw reply [flat|nested] 2+ messages in thread
* [Bug sanitizer/108903] ASAN may miss a global-buffer-overflow
2023-02-23 12:01 [Bug sanitizer/108903] New: ASAN may miss a global-buffer-overflow shaohua.li at inf dot ethz.ch
@ 2023-02-23 14:11 ` marxin at gcc dot gnu.org
0 siblings, 0 replies; 2+ messages in thread
From: marxin at gcc dot gnu.org @ 2023-02-23 14:11 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108903
Martin Liška <marxin at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Resolution|--- |INVALID
Status|UNCONFIRMED |RESOLVED
--- Comment #1 from Martin Liška <marxin at gcc dot gnu.org> ---
>
> 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 <bb 4>; [5.50%]
> else
> goto <bb 7>; [94.50%]
>
> <bb 4> [local count: 55807731]:
> _49 = (unsigned long) &MEM[(int *)&e + 4B];
> _43 = _49 >> 3;
> _10 = _43 + 2147450880;
> ..
> $
Good, we can close it then.
>
> 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.
It's address of e + 4, which is fine.
^ permalink raw reply [flat|nested] 2+ messages in thread
end of thread, other threads:[~2023-02-23 14:11 UTC | newest]
Thread overview: 2+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2023-02-23 12:01 [Bug sanitizer/108903] New: ASAN may miss a global-buffer-overflow shaohua.li at inf dot ethz.ch
2023-02-23 14:11 ` [Bug sanitizer/108903] " 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).