public inbox for gcc-bugs@sourceware.org
help / color / mirror / Atom feed
* [Bug sanitizer/107619] New: False positive of -fsanitize=null
@ 2022-11-10 16:12 shaohua.li at inf dot ethz.ch
2022-11-10 16:18 ` [Bug sanitizer/107619] " jakub at gcc dot gnu.org
0 siblings, 1 reply; 2+ messages in thread
From: shaohua.li at inf dot ethz.ch @ 2022-11-10 16:12 UTC (permalink / raw)
To: gcc-bugs
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;
}
%
^ permalink raw reply [flat|nested] 2+ messages in thread
* [Bug sanitizer/107619] False positive of -fsanitize=null
2022-11-10 16:12 [Bug sanitizer/107619] New: False positive of -fsanitize=null shaohua.li at inf dot ethz.ch
@ 2022-11-10 16:18 ` jakub at gcc dot gnu.org
0 siblings, 0 replies; 2+ messages in thread
From: jakub at gcc dot gnu.org @ 2022-11-10 16:18 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107619
Jakub Jelinek <jakub at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Resolution|--- |INVALID
Status|UNCONFIRMED |RESOLVED
--- Comment #1 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
After you overflow the buffer, all bets are off. It can but doesn't have to
overwrite unrelated variables around, and which exact depends on the
optimization flags, architecture and how exactly the compiler decides to lay
stuff out.
User -fsanitize=address to detect such buffer overflows, fix them and then
ubsan behavior will be sane.
^ permalink raw reply [flat|nested] 2+ messages in thread
end of thread, other threads:[~2022-11-10 16:18 UTC | newest]
Thread overview: 2+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2022-11-10 16:12 [Bug sanitizer/107619] New: False positive of -fsanitize=null shaohua.li at inf dot ethz.ch
2022-11-10 16:18 ` [Bug sanitizer/107619] " jakub 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).