1

As I was configuring the kernel 5.4.0 with:

CONFIG_UBSAN=y
UBSAN_SANITIZE_ALL=y

and -fsanitize=signed-integer-overflow also appeared in gcc command during compilation.

However, in the final vmlinux, __ubsan_handle_add_overflow was in the image, but never called.

In contrast, other non signed-integer-overflow UBSan handlers e.g. __ubsan_handle_load_invalid_value, __ubsan_handle_shift_out_of_bounds were called extensively.

I couldn't find any difference between these 2 types of UBSan throughout the compilation process. Is it maybe because the compiler optimization assuming that overflow should never exist, thus didn't instrument these overflow-related UBSan?

I attached a typical gcc command here in case it might be needed:

cmd_fs/ioctl.o := /home/cm/exp/symslice/syzkaller/gcc/bin/gcc -Wp,-MD,fs/.ioctl.o.d -nostdinc -isystem /home/cm/exp/symslice/syzkaller/gcc/bin/../lib/gcc/x86_64-pc-linux-gnu/8.0.1/include -I./arch/x86/include -I./arch/x86/include/generated -I./include -I./arch/x86/include/uapi -I./arch/x86/include/generated/uapi -I./include/uapi -I./include/generated/uapi -include ./include/linux/kconfig.h -include ./include/linux/compiler_types.h -D__KERNEL__ -Wall -Wundef -Werror=strict-prototypes -Wno-trigraphs -fno-strict-aliasing -fno-common -fshort-wchar -fno-PIE -Werror=implicit-function-declaration -Werror=implicit-int -Wno-format-security -std=gnu89 -mno-sse -mno-mmx -mno-sse2 -mno-3dnow -mno-avx -m64 -falign-jumps=1 -falign-loops=1 -mno-80387 -mno-fp-ret-in-387 -mpreferred-stack-boundary=3 -mskip-rax-setup -march=core2 -mno-red-zone -mcmodel=kernel -DCONFIG_X86_X32_ABI -DCONFIG_AS_CFI=1 -DCONFIG_AS_CFI_SIGNAL_FRAME=1 -DCONFIG_AS_CFI_SECTIONS=1 -DCONFIG_AS_SSSE3=1 -DCONFIG_AS_AVX=1 -DCONFIG_AS_AVX2=1 -DCONFIG_AS_AVX512=1 -DCONFIG_AS_SHA1_NI=1 -DCONFIG_AS_SHA256_NI=1 -Wno-sign-compare -fno-asynchronous-unwind-tables -fno-delete-null-pointer-checks -Wno-frame-address -Wno-format-truncation -Wno-format-overflow -O2 --param=allow-store-data-races=0 -Wframe-larger-than=2048 -fstack-protector-strong -Wno-unused-but-set-variable -Wimplicit-fallthrough -Wno-unused-const-variable -fomit-frame-pointer -fno-var-tracking-assignments -g -femit-struct-debug-baseonly -fno-var-tracking -Wdeclaration-after-statement -Wvla -Wno-pointer-sign -Wno-stringop-truncation -fno-strict-overflow -fno-merge-all-constants -fmerge-constants -fno-stack-check -fconserve-stack -Werror=date-time -Werror=incompatible-pointer-types -Werror=designated-init -fmacro-prefix-map=./= -Wno-packed-not-aligned -fsanitize=kernel-address -fasan-shadow-offset=0xdffffc0000000000 --param asan-globals=1 --param asan-instrumentation-with-call-threshold=10000 --param asan-stack=1 --param asan-instrument-allocas=1 -fsanitize=shift -fsanitize=integer-divide-by-zero -fsanitize=unreachable -fsanitize=signed-integer-overflow -fsanitize=bounds -fsanitize=object-size -fsanitize=bool -fsanitize=enum -Wno-maybe-uninitialized -fsanitize-coverage=trace-pc -fsanitize-coverage=trace-cmp -DKBUILD_BASENAME='"ioctl"' -DKBUILD_MODNAME='"ioctl"' -c -o fs/ioctl.o fs/ioctl.c

General Grievance
  • 4,555
  • 31
  • 31
  • 45
Charley
  • 69
  • 1
  • 3

1 Answers1

0

You’re compiling with -fno-strict-overflow, meaning overflow when adding signed numbers is not treated as UB.

Sneftel
  • 40,271
  • 12
  • 71
  • 104
  • After poking around, I tried different compilers provided by syzkaller here, https://github.com/google/syzkaller/blob/master/docs/syzbot.md#crash-does-not-reproduce, I downgraded my gcc from 8.0.0 to 7.0.0, and everything is back to normal.(__ubsan_handle_add_overflow is now called extensively), guess it's some compatibility issue from gcc. – Charley Nov 16 '20 at 01:00
  • gcc.gnu.org/onlinedocs/gcc-5.4.0/gcc/Optimize-Options.html, according to this document, it seems -fno-strict-overflow just disallow optimizer from exploiting UB to do some crazy optimization? It looks to me like, linux has to be compiled with -O2, in this case, if no `-fno-strict-overflow` is given, then `-fstrict-overflow` is turned on by default, as a result gcc will just optimize the hell out of Linux, so `-fno-strict-overflow` seems like a must-have to me. – Charley Nov 16 '20 at 01:02