public inbox for gcc-bugs@sourceware.org
help / color / mirror / Atom feed
* [Bug sanitizer/107866] New: gcc trunk's UBSan misses a Nll-pointer-dereference at -O3.
@ 2022-11-25 9:32 shaohua.li at inf dot ethz.ch
2022-11-25 10:40 ` [Bug sanitizer/107866] [12/13 Regression] gcc trunk's UBSan misses a Null-pointer-dereference " jakub at gcc dot gnu.org
` (4 more replies)
0 siblings, 5 replies; 6+ messages in thread
From: shaohua.li at inf dot ethz.ch @ 2022-11-25 9:32 UTC (permalink / raw)
To: gcc-bugs
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'
%
^ permalink raw reply [flat|nested] 6+ messages in thread
* [Bug sanitizer/107866] [12/13 Regression] gcc trunk's UBSan misses a Null-pointer-dereference at -O3.
2022-11-25 9:32 [Bug sanitizer/107866] New: gcc trunk's UBSan misses a Nll-pointer-dereference at -O3 shaohua.li at inf dot ethz.ch
@ 2022-11-25 10:40 ` jakub at gcc dot gnu.org
2022-11-25 10:56 ` shaohua.li at inf dot ethz.ch
` (3 subsequent siblings)
4 siblings, 0 replies; 6+ messages in thread
From: jakub at gcc dot gnu.org @ 2022-11-25 10:40 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107866
Jakub Jelinek <jakub at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Summary|gcc trunk's UBSan misses a |[12/13 Regression] gcc
|Null-pointer-dereference at |trunk's UBSan misses a
|-O3. |Null-pointer-dereference at
| |-O3.
Target Milestone|--- |12.3
CC| |rguenth at gcc dot gnu.org
Priority|P3 |P2
--- Comment #1 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
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.
^ permalink raw reply [flat|nested] 6+ messages in thread
* [Bug sanitizer/107866] [12/13 Regression] gcc trunk's UBSan misses a Null-pointer-dereference at -O3.
2022-11-25 9:32 [Bug sanitizer/107866] New: gcc trunk's UBSan misses a Nll-pointer-dereference at -O3 shaohua.li at inf dot ethz.ch
2022-11-25 10:40 ` [Bug sanitizer/107866] [12/13 Regression] gcc trunk's UBSan misses a Null-pointer-dereference " jakub at gcc dot gnu.org
@ 2022-11-25 10:56 ` shaohua.li at inf dot ethz.ch
2022-11-25 12:20 ` marxin at gcc dot gnu.org
` (2 subsequent siblings)
4 siblings, 0 replies; 6+ messages in thread
From: shaohua.li at inf dot ethz.ch @ 2022-11-25 10:56 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107866
--- Comment #2 from Li Shaohua <shaohua.li at inf dot ethz.ch> ---
(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.
^ permalink raw reply [flat|nested] 6+ messages in thread
* [Bug sanitizer/107866] [12/13 Regression] gcc trunk's UBSan misses a Null-pointer-dereference at -O3.
2022-11-25 9:32 [Bug sanitizer/107866] New: gcc trunk's UBSan misses a Nll-pointer-dereference at -O3 shaohua.li at inf dot ethz.ch
2022-11-25 10:40 ` [Bug sanitizer/107866] [12/13 Regression] gcc trunk's UBSan misses a Null-pointer-dereference " jakub at gcc dot gnu.org
2022-11-25 10:56 ` shaohua.li at inf dot ethz.ch
@ 2022-11-25 12:20 ` marxin at gcc dot gnu.org
2022-11-25 12:36 ` rguenth at gcc dot gnu.org
2023-05-08 12:26 ` [Bug sanitizer/107866] [12/13/14 " rguenth at gcc dot gnu.org
4 siblings, 0 replies; 6+ messages in thread
From: marxin at gcc dot gnu.org @ 2022-11-25 12:20 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107866
Martin Liška <marxin at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Last reconfirmed| |2022-11-25
Ever confirmed|0 |1
Status|UNCONFIRMED |NEW
^ permalink raw reply [flat|nested] 6+ messages in thread
* [Bug sanitizer/107866] [12/13 Regression] gcc trunk's UBSan misses a Null-pointer-dereference at -O3.
2022-11-25 9:32 [Bug sanitizer/107866] New: gcc trunk's UBSan misses a Nll-pointer-dereference at -O3 shaohua.li at inf dot ethz.ch
` (2 preceding siblings ...)
2022-11-25 12:20 ` marxin at gcc dot gnu.org
@ 2022-11-25 12:36 ` rguenth at gcc dot gnu.org
2023-05-08 12:26 ` [Bug sanitizer/107866] [12/13/14 " rguenth at gcc dot gnu.org
4 siblings, 0 replies; 6+ messages in thread
From: rguenth at gcc dot gnu.org @ 2022-11-25 12:36 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107866
--- Comment #3 from Richard Biener <rguenth at gcc dot gnu.org> ---
For some reason we think that the .UBSAN_NULL call doesn't clobber the load
from nullptr:
<bb 2> [local count: 118111600]:
+ # VUSE <.MEM_3(D)>
+ pretmp_7 = MEM[(int *)0B];
<bb 3> [local count: 1073741824]:
- # .MEM_2 = PHI <.MEM_3(D)(2), .MEM_6(5)>
+ # .MEM_2 = PHI <.MEM_3(D)(2), .MEM_6(3)>
# .MEM_4 = VDEF <.MEM_2>
a = 0B;
# .MEM_6 = VDEF <.MEM_4>
# USE = nonlocal escaped
# CLB = nonlocal escaped
.UBSAN_NULL (0B, 0B, 4);
- # VUSE <.MEM_6>
- _1 = MEM[(int *)0B];
- if (_1 != 0)
+ if (pretmp_7 != 0)
that's because
DEF_INTERNAL_FN (UBSAN_NULL, ECF_LEAF | ECF_NOTHROW, ". R . ")
and thus .UBSAN_NULL only _reads_ from the first argument passed (but also
possibly constant NULL(?) valued operands are considered special). The
same happens at -O2 btw. At -O1 we eliminate the load.
Ah, and call_may_clobber_ref_p_1 has
if (gimple_call_internal_p (call))
switch (auto fn = gimple_call_internal_fn (call))
{
/* Treat these internal calls like ECF_PURE for aliasing,
they don't write to any memory the program should care about.
They have important other side-effects, and read memory,
so can't be ECF_NOVOPS. */
case IFN_UBSAN_NULL:
case IFN_UBSAN_BOUNDS:
case IFN_UBSAN_VPTR:
case IFN_UBSAN_OBJECT_SIZE:
case IFN_UBSAN_PTR:
case IFN_ASAN_CHECK:
return false;
so they are not a barrier for the motion of loads which is what happens
here.
Note that only at -O3 we keep the trapping load because we fail to eliminate
the conditional there and have
<bb 2> [local count: 118111600]:
# VUSE <.MEM_3(D)>
pretmp_7 = MEM[(int *)0B];
if (pretmp_7 != 0)
goto <bb 4>; [11.00%]
else
goto <bb 3>; [89.00%]
<bb 3> [local count: 955630224]:
# .MEM_1 = PHI <.MEM_3(D)(2)>
# .MEM_8 = VDEF <.MEM_1>
a = 0B;
# .MEM_11 = VDEF <.MEM_8>
# USE = anything
# CLB = anything
__builtin___ubsan_handle_type_mismatch_v1_abort (&*.Lubsan_data0, 0);
<bb 4> [local count: 118111600]:
# .MEM_4 = VDEF <.MEM_3(D)>
a = 0B;
# .MEM_10 = VDEF <.MEM_4>
# USE = anything
# CLB = anything
__builtin___ubsan_handle_type_mismatch_v1_abort (&*.Lubsan_data1, 0);
in the end.
^ permalink raw reply [flat|nested] 6+ messages in thread
* [Bug sanitizer/107866] [12/13/14 Regression] gcc trunk's UBSan misses a Null-pointer-dereference at -O3.
2022-11-25 9:32 [Bug sanitizer/107866] New: gcc trunk's UBSan misses a Nll-pointer-dereference at -O3 shaohua.li at inf dot ethz.ch
` (3 preceding siblings ...)
2022-11-25 12:36 ` rguenth at gcc dot gnu.org
@ 2023-05-08 12:26 ` rguenth at gcc dot gnu.org
4 siblings, 0 replies; 6+ messages in thread
From: rguenth at gcc dot gnu.org @ 2023-05-08 12:26 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107866
Richard Biener <rguenth at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Target Milestone|12.3 |12.4
--- Comment #4 from Richard Biener <rguenth at gcc dot gnu.org> ---
GCC 12.3 is being released, retargeting bugs to GCC 12.4.
^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2023-05-08 12:26 UTC | newest]
Thread overview: 6+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2022-11-25 9:32 [Bug sanitizer/107866] New: gcc trunk's UBSan misses a Nll-pointer-dereference at -O3 shaohua.li at inf dot ethz.ch
2022-11-25 10:40 ` [Bug sanitizer/107866] [12/13 Regression] gcc trunk's UBSan misses a Null-pointer-dereference " jakub at gcc dot gnu.org
2022-11-25 10:56 ` shaohua.li at inf dot ethz.ch
2022-11-25 12:20 ` marxin at gcc dot gnu.org
2022-11-25 12:36 ` rguenth at gcc dot gnu.org
2023-05-08 12:26 ` [Bug sanitizer/107866] [12/13/14 " rguenth 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).