[Bug sanitizer/107866] New: gcc trunk's UBSan misses a Nll-pointer-dereference at -O3.

[Bug sanitizer/107866] New: gcc trunk's UBSan misses a Nll-pointer-dereference at -O3.

[shaohua.li at inf dot ethz.ch]

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.

[jakub at gcc dot gnu.org]

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.

[Bug sanitizer/107866] [12/13 Regression] gcc trunk's UBSan misses a Null-pointer-dereference at -O3.

[shaohua.li at inf dot ethz.ch]

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.

[Bug sanitizer/107866] [12/13 Regression] gcc trunk's UBSan misses a Null-pointer-dereference at -O3.

[marxin at gcc dot gnu.org]

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

[Bug sanitizer/107866] [12/13 Regression] gcc trunk's UBSan misses a Null-pointer-dereference at -O3.

[rguenth at gcc dot gnu.org]

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.

[Bug sanitizer/107866] [12/13/14 Regression] gcc trunk's UBSan misses a Null-pointer-dereference at -O3.

[rguenth at gcc dot gnu.org]

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.