Add additional undefined behaviors

[mikea]

Current config: bool,signed-integer-overflow,shift,vptr

[Dor1s]

What do you think about function? We've seen some of them detected on internal CF.

[inferno-chromium]

We have https://cs.chromium.org/chromium/src/build/config/sanitizers/BUILD.gn?rcl=bbf5af70f469a5f7807ec4573a65c3710cfbb29a&l=512

Should we enable function, vla-bound. How about others ?

[inferno-chromium]

@Dor1s - when you get time, can you add parsing signature+test for vla-bound (don't see in current clusterfuzz code) and then we can enable it here.

[Dor1s]

I have a feeling that we treat vla-bound errors as heap-buffer-overflow, but not 100% sure... I'll take a look soon. Do we want it filed as a separate issue?

[inferno-chromium]

Yes probably, but what about if we skip past the left redzone for a large negative value. We can probably wait on @kcc to respond here if vla-bound is even needed since ASAN should probably catch this.

[Dor1s]

I mixed up that with -fsanitize=bounds (Out of bounds array indexing, in cases where the array bound can be statically determined), this is what we report as heap-buffer-overflow.

vla-bound is only for cases like this:

$ cat vla.cc 
int main(int argc, char* argv[]) {
  int n = 5;
  n -= 10;
  int a[n];
  return 0;
}

$ clang vla.cc -fsanitize=vla-bound -o vla && ./vla 
vla.cc:4:9: runtime error: variable length array bound evaluates to non-positive value -5

ASan doesn't report an attempt to declare an array with a negative size:

$ clang vla.cc -fsanitize=address -o vla && ./vla 
$ echo $?
0

But reports an attempt to use it, e.g.:

$ cat vla.cc 
#include <stdio.h>

int main(int argc, char* argv[]) {
  int n = 5;
  n -= 10;
  int a[n];
  printf("%i\n", a[0]);
  return 0;
}

$ clang vla.cc -fsanitize=address -o vla && ./vla 
ASAN:DEADLYSIGNAL
=================================================================
==11176==ERROR: AddressSanitizer: stack-overflow on address 0x7ff9f171d358 (pc 0x0000004ec705 bp 0x7ffdf171d440 sp 0x7ff9f171d360 T0)
    #0 0x4ec704 in main (/usr/local/google/home/mmoroz/Projects/clusterfuzz/vla+0x4ec704)
    #1 0x7f5b52872f44 in __libc_start_main /build/eglibc-oGUzwX/eglibc-2.19/csu/libc-start.c:287
    #2 0x41977b in _start (/usr/local/google/home/mmoroz/Projects/clusterfuzz/vla+0x41977b)

SUMMARY: AddressSanitizer: stack-overflow (/usr/local/google/home/mmoroz/Projects/clusterfuzz/vla+0x4ec704) in main
==11176==ABORTING

$ echo $?
1

[Dor1s]

Hm, strange. The following code:

#include <stdio.h>

int main(int argc, char* argv[]) {
  int n = 5;
  n -= 10;
  int a[n];
  printf("%lu\n", sizeof(a));
  return 0;
}

doesn't break with ASan:

$ clang vla.cc -g -fsanitize=address -o vla && ASAN_OPTIONS=symbolzie=1 ./vla 
17179869164

$ echo $?
0

So probably it makes sense to be added, but +1 to wait for @kcc

[kcc]

Hm... I've no opinion and no experience with -fsanitize=vla-bound.
In particular, I don't know a situation when such bug will not lead to a stack overflow.
(in your case, int a[n] is not used and so is optimized away).

Perhaps it's still worth trying.

[Dor1s]

I also thought that it might haave been optimized away, but why it is not omitted when building with UBSan...

Ok, let's add it and see if we catch anything unique!

[Dor1s]

It seems that declaration of a variable-length array with a negative length ends up as an arbitrary pointer in memory:

1. VLA of length 5:

mov     [rbp+n], 5
mov     edi, [rbp+n]
mov     esi, edi
mov     rcx, rsp
mov     [rbp+var_20], rcx

2. VLA of length -5:

mov     [rbp+n], 5
mov     edi, [rbp+n]
add     edi, 0FFFFFFF6h
mov     [rbp+n], edi
mov     edi, [rbp+n]
mov     esi, edi
mov     rcx, rsp
mov     [rbp+var_20], rcx

Due to that, we should mark vla-bound crashes as security issues by default.

[inferno-chromium]

Thanks Max for adding the parsing signatures, enabled vla-bound in 921f143.