From patchwork Thu Feb 27 19:35:11 2020 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Kees Cook X-Patchwork-Id: 11409567 Return-Path: Received: from mail.kernel.org (pdx-korg-mail-1.web.codeaurora.org [172.30.200.123]) by pdx-korg-patchwork-2.web.codeaurora.org (Postfix) with ESMTP id 720AA159A for ; Thu, 27 Feb 2020 19:35:55 +0000 (UTC) Received: from mother.openwall.net (mother.openwall.net [195.42.179.200]) by mail.kernel.org (Postfix) with SMTP id A406D246A2 for ; Thu, 27 Feb 2020 19:35:54 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (1024-bit key) header.d=chromium.org header.i=@chromium.org header.b="eKbq1uyx" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org A406D246A2 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=chromium.org Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=kernel-hardening-return-17986-patchwork-kernel-hardening=patchwork.kernel.org@lists.openwall.com Received: (qmail 1751 invoked by uid 550); 27 Feb 2020 19:35:36 -0000 Mailing-List: contact kernel-hardening-help@lists.openwall.com; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-ID: Delivered-To: mailing list kernel-hardening@lists.openwall.com Received: (qmail 1532 invoked from network); 27 Feb 2020 19:35:35 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=chromium.org; s=google; h=from:to:cc:subject:date:message-id:in-reply-to:references :mime-version:content-transfer-encoding; bh=ouVhJC1LzbMtIjBpkBkXzJDLKbzWPj7ADPmF+3aq9S8=; b=eKbq1uyxj9sdlKd8KWlneIzqahwkro68DRX4rRBijPFKNce5ok5QxzJT6Ig9AabiKE 6wTImMPfJk6hvjOiqFoNJIrRNWOqk/eMQzD3Sn8a3wtYnD8lTY/23SEpWi1CDHEb78B+ UP8RTZTWnKxekxqZDolSm+CIiKJsffOwIQXck= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:subject:date:message-id:in-reply-to :references:mime-version:content-transfer-encoding; bh=ouVhJC1LzbMtIjBpkBkXzJDLKbzWPj7ADPmF+3aq9S8=; b=VAepFsp+6ahFeXLwoLYyT50P+arY6P6YSRIrQnoqqeNMBgm/1C1UaSgCmv5+qHcBzP 8VHG2B83bOIrINQQAHW8uNev/wR9YBZeXzDWUPPDtR0fUrcmtLEASU7LyujWpTqwaQqO zvVx3Wdv3XYWOQO0DMN97YfGZNmmOjPdNh+19aKhDTV49im+FjyYPIMaouKzbkO+WZIN LUwZM6h/wHmuz1NLGKpOpHppaFLXlOQvfuH5HD1+Gvx88GfVtoBkRwyPgmhrQYfMmIS+ xhBDroNbKTKrMZLyFebB3bRCztcoUwiyZlrxQmys5iDgFNg19kI9Pz0ONitJulPdSiV9 bLRw== X-Gm-Message-State: APjAAAXN6utx65AR8XDGqiNv7v1FoiZvUCDSqqAwQrkMfIRDNY79K53S mU/c0IrolWYuXPNJVUfnvvzAIQ== X-Google-Smtp-Source: APXvYqxTwZu2muMNOSE/MnDg7HrxUrqj2WJlHpWI6A4QY/3Gzc92Hs6WuLhx1gx2liU6bGiSGd3vuA== X-Received: by 2002:a17:902:ba8a:: with SMTP id k10mr312829pls.333.1582832123523; Thu, 27 Feb 2020 11:35:23 -0800 (PST) From: Kees Cook To: Andrew Morton Cc: Kees Cook , Elena Petrova , Dmitry Vyukov , Andrey Ryabinin , Andrey Konovalov , Alexander Potapenko , Dan Carpenter , "Gustavo A. R. Silva" , Arnd Bergmann , Ard Biesheuvel , kasan-dev@googlegroups.com, linux-mm@kvack.org, linux-kernel@vger.kernel.org, kernel-hardening@lists.openwall.com, syzkaller@googlegroups.com Subject: [PATCH v5 1/6] ubsan: Add trap instrumentation option Date: Thu, 27 Feb 2020 11:35:11 -0800 Message-Id: <20200227193516.32566-2-keescook@chromium.org> X-Mailer: git-send-email 2.20.1 In-Reply-To: <20200227193516.32566-1-keescook@chromium.org> References: <20200227193516.32566-1-keescook@chromium.org> MIME-Version: 1.0 The Undefined Behavior Sanitizer can operate in two modes: warning reporting mode via lib/ubsan.c handler calls, or trap mode, which uses __builtin_trap() as the handler. Using lib/ubsan.c means the kernel image is about 5% larger (due to all the debugging text and reporting structures to capture details about the warning conditions). Using the trap mode, the image size changes are much smaller, though at the loss of the "warning only" mode. In order to give greater flexibility to system builders that want minimal changes to image size and are prepared to deal with kernel code being aborted and potentially destabilizing the system, this introduces CONFIG_UBSAN_TRAP. The resulting image sizes comparison: text data bss dec hex filename 19533663 6183037 18554956 44271656 2a38828 vmlinux.stock 19991849 7618513 18874448 46484810 2c54d4a vmlinux.ubsan 19712181 6284181 18366540 44362902 2a4ec96 vmlinux.ubsan-trap CONFIG_UBSAN=y: image +4.8% (text +2.3%, data +18.9%) CONFIG_UBSAN_TRAP=y: image +0.2% (text +0.9%, data +1.6%) Additionally adjusts the CONFIG_UBSAN Kconfig help for clarity and removes the mention of non-existing boot param "ubsan_handle". Suggested-by: Elena Petrova Signed-off-by: Kees Cook Acked-by: Dmitry Vyukov --- lib/Kconfig.ubsan | 22 ++++++++++++++++++---- lib/Makefile | 2 ++ scripts/Makefile.ubsan | 9 +++++++-- 3 files changed, 27 insertions(+), 6 deletions(-) diff --git a/lib/Kconfig.ubsan b/lib/Kconfig.ubsan index 0e04fcb3ab3d..9deb655838b0 100644 --- a/lib/Kconfig.ubsan +++ b/lib/Kconfig.ubsan @@ -5,11 +5,25 @@ config ARCH_HAS_UBSAN_SANITIZE_ALL config UBSAN bool "Undefined behaviour sanity checker" help - This option enables undefined behaviour sanity checker + This option enables the Undefined Behaviour sanity checker. Compile-time instrumentation is used to detect various undefined - behaviours in runtime. Various types of checks may be enabled - via boot parameter ubsan_handle - (see: Documentation/dev-tools/ubsan.rst). + behaviours at runtime. For more details, see: + Documentation/dev-tools/ubsan.rst + +config UBSAN_TRAP + bool "On Sanitizer warnings, abort the running kernel code" + depends on UBSAN + depends on $(cc-option, -fsanitize-undefined-trap-on-error) + help + Building kernels with Sanitizer features enabled tends to grow + the kernel size by around 5%, due to adding all the debugging + text on failure paths. To avoid this, Sanitizer instrumentation + can just issue a trap. This reduces the kernel size overhead but + turns all warnings (including potentially harmless conditions) + into full exceptions that abort the running kernel code + (regardless of context, locks held, etc), which may destabilize + the system. For some system builders this is an acceptable + trade-off. config UBSAN_SANITIZE_ALL bool "Enable instrumentation for the entire kernel" diff --git a/lib/Makefile b/lib/Makefile index 611872c06926..55cc8d73cd43 100644 --- a/lib/Makefile +++ b/lib/Makefile @@ -279,7 +279,9 @@ quiet_cmd_build_OID_registry = GEN $@ clean-files += oid_registry_data.c obj-$(CONFIG_UCS2_STRING) += ucs2_string.o +ifneq ($(CONFIG_UBSAN_TRAP),y) obj-$(CONFIG_UBSAN) += ubsan.o +endif UBSAN_SANITIZE_ubsan.o := n KASAN_SANITIZE_ubsan.o := n diff --git a/scripts/Makefile.ubsan b/scripts/Makefile.ubsan index 019771b845c5..668a91510bfe 100644 --- a/scripts/Makefile.ubsan +++ b/scripts/Makefile.ubsan @@ -1,5 +1,10 @@ # SPDX-License-Identifier: GPL-2.0 ifdef CONFIG_UBSAN + +ifdef CONFIG_UBSAN_ALIGNMENT + CFLAGS_UBSAN += $(call cc-option, -fsanitize=alignment) +endif + CFLAGS_UBSAN += $(call cc-option, -fsanitize=shift) CFLAGS_UBSAN += $(call cc-option, -fsanitize=integer-divide-by-zero) CFLAGS_UBSAN += $(call cc-option, -fsanitize=unreachable) @@ -9,8 +14,8 @@ ifdef CONFIG_UBSAN CFLAGS_UBSAN += $(call cc-option, -fsanitize=bool) CFLAGS_UBSAN += $(call cc-option, -fsanitize=enum) -ifdef CONFIG_UBSAN_ALIGNMENT - CFLAGS_UBSAN += $(call cc-option, -fsanitize=alignment) +ifdef CONFIG_UBSAN_TRAP + CFLAGS_UBSAN += $(call cc-option, -fsanitize-undefined-trap-on-error) endif # -fsanitize=* options makes GCC less smart than usual and From patchwork Thu Feb 27 19:35:12 2020 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Kees Cook X-Patchwork-Id: 11409565 Return-Path: Received: from mail.kernel.org (pdx-korg-mail-1.web.codeaurora.org [172.30.200.123]) by pdx-korg-patchwork-2.web.codeaurora.org (Postfix) with ESMTP id 727D4159A for ; Thu, 27 Feb 2020 19:35:48 +0000 (UTC) Received: from mother.openwall.net (mother.openwall.net [195.42.179.200]) by mail.kernel.org (Postfix) with SMTP id 9C3402469C for ; Thu, 27 Feb 2020 19:35:47 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (1024-bit key) header.d=chromium.org header.i=@chromium.org header.b="fhU4ZWts" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 9C3402469C Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=chromium.org Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=kernel-hardening-return-17985-patchwork-kernel-hardening=patchwork.kernel.org@lists.openwall.com Received: (qmail 1571 invoked by uid 550); 27 Feb 2020 19:35:35 -0000 Mailing-List: contact kernel-hardening-help@lists.openwall.com; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-ID: Delivered-To: mailing list kernel-hardening@lists.openwall.com Received: (qmail 1498 invoked from network); 27 Feb 2020 19:35:34 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=chromium.org; s=google; h=from:to:cc:subject:date:message-id:in-reply-to:references :mime-version:content-transfer-encoding; bh=TZN5E5934TvMDmRyA6YbiUZA3oVW+HYGx9jzlGs1fas=; b=fhU4ZWtsMwSX2mupe2qPd38EZqvMNduMdASxFGXOeV4vpARzuW/YSPVaTMFGN08Hhc XliIaYkwUiNY8jqwNeYkG4jQoqhhnqvlU2l4wKiF6qSNMzXt1xWnxElExOLM5ZL41m7y Z7z1AWZH5EHP1O9W7xlNQcsJwhj4eFUdEyy5Q= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:subject:date:message-id:in-reply-to :references:mime-version:content-transfer-encoding; bh=TZN5E5934TvMDmRyA6YbiUZA3oVW+HYGx9jzlGs1fas=; b=dXTYpVYOwKzjq+I9xEvErAbE5cigJcNCDxEb1w0aWdqfr7LY9Zaz01FIoun3tVro6T 8HFktRloN4/ArzDk+skHlphyMsah4tJfgNhVg309ZuRO/4PQ36a9GTlCbuPhWP7Ndba0 P3sEj7g8+xiFIMW0pF8gxacor2R14eW2Kfr6R1dLXzI2G6YmfTKbT2QZIB7dtUBIVc5y 9az3gFyF3TE3BMlmWwhuUgITCPwlfVmp8eQllwGS0zMiao8luCcGa7KL7wQ9M1elakWe j7zFyP9rnWjO72qvjqW9jT3IoCT6I0/u3rSPOzJ6Y1N+eZ116SzEAhYorkO54eEzhrrO clbA== X-Gm-Message-State: APjAAAU8mwTew5FbuO6D8SfZ/enqL2F2tHVbbs+SzsQYfXSAVy0qhgRz KOAlaPdNb6LzZFBBn06fyF9sTQ== X-Google-Smtp-Source: APXvYqy8bVQH818HJGFZc2ql+d1GQcz5CnyZ/Lu/Mb9ddeqTtnjcaB2N07vWUnQwqSXTy5cLxuMyQA== X-Received: by 2002:a17:902:7048:: with SMTP id h8mr383251plt.64.1582832122570; Thu, 27 Feb 2020 11:35:22 -0800 (PST) From: Kees Cook To: Andrew Morton Cc: Kees Cook , Elena Petrova , Andrey Ryabinin , Dmitry Vyukov , Andrey Konovalov , Alexander Potapenko , Dan Carpenter , "Gustavo A. R. Silva" , Arnd Bergmann , Ard Biesheuvel , kasan-dev@googlegroups.com, linux-mm@kvack.org, linux-kernel@vger.kernel.org, kernel-hardening@lists.openwall.com, syzkaller@googlegroups.com Subject: [PATCH v5 2/6] ubsan: Split "bounds" checker from other options Date: Thu, 27 Feb 2020 11:35:12 -0800 Message-Id: <20200227193516.32566-3-keescook@chromium.org> X-Mailer: git-send-email 2.20.1 In-Reply-To: <20200227193516.32566-1-keescook@chromium.org> References: <20200227193516.32566-1-keescook@chromium.org> MIME-Version: 1.0 In order to do kernel builds with the bounds checker individually available, introduce CONFIG_UBSAN_BOUNDS, with the remaining options under CONFIG_UBSAN_MISC. For example, using this, we can start to expand the coverage syzkaller is providing. Right now, all of UBSan is disabled for syzbot builds because taken as a whole, it is too noisy. This will let us focus on one feature at a time. For the bounds checker specifically, this provides a mechanism to eliminate an entire class of array overflows with close to zero performance overhead (I cannot measure a difference). In my (mostly) defconfig, enabling bounds checking adds ~4200 checks to the kernel. Performance changes are in the noise, likely due to the branch predictors optimizing for the non-fail path. Some notes on the bounds checker: - it does not instrument {mem,str}*()-family functions, it only instruments direct indexed accesses (e.g. "foo[i]"). Dealing with the {mem,str}*()-family functions is a work-in-progress around CONFIG_FORTIFY_SOURCE[1]. - it ignores flexible array members, including the very old single byte (e.g. "int foo[1];") declarations. (Note that GCC's implementation appears to ignore _all_ trailing arrays, but Clang only ignores empty, 0, and 1 byte arrays[2].) [1] https://github.com/KSPP/linux/issues/6 [2] https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92589 Suggested-by: Elena Petrova Signed-off-by: Kees Cook Reviewed-by: Andrey Ryabinin Acked-by: Dmitry Vyukov --- lib/Kconfig.ubsan | 29 ++++++++++++++++++++++++----- scripts/Makefile.ubsan | 7 ++++++- 2 files changed, 30 insertions(+), 6 deletions(-) diff --git a/lib/Kconfig.ubsan b/lib/Kconfig.ubsan index 9deb655838b0..48469c95d78e 100644 --- a/lib/Kconfig.ubsan +++ b/lib/Kconfig.ubsan @@ -2,7 +2,7 @@ config ARCH_HAS_UBSAN_SANITIZE_ALL bool -config UBSAN +menuconfig UBSAN bool "Undefined behaviour sanity checker" help This option enables the Undefined Behaviour sanity checker. @@ -10,9 +10,10 @@ config UBSAN behaviours at runtime. For more details, see: Documentation/dev-tools/ubsan.rst +if UBSAN + config UBSAN_TRAP bool "On Sanitizer warnings, abort the running kernel code" - depends on UBSAN depends on $(cc-option, -fsanitize-undefined-trap-on-error) help Building kernels with Sanitizer features enabled tends to grow @@ -25,9 +26,26 @@ config UBSAN_TRAP the system. For some system builders this is an acceptable trade-off. +config UBSAN_BOUNDS + bool "Perform array index bounds checking" + default UBSAN + help + This option enables detection of directly indexed out of bounds + array accesses, where the array size is known at compile time. + Note that this does not protect array overflows via bad calls + to the {str,mem}*cpy() family of functions (that is addressed + by CONFIG_FORTIFY_SOURCE). + +config UBSAN_MISC + bool "Enable all other Undefined Behavior sanity checks" + default UBSAN + help + This option enables all sanity checks that don't have their + own Kconfig options. Disable this if you only want to have + individually selected checks. + config UBSAN_SANITIZE_ALL bool "Enable instrumentation for the entire kernel" - depends on UBSAN depends on ARCH_HAS_UBSAN_SANITIZE_ALL # We build with -Wno-maybe-uninitilzed, but we still want to @@ -44,7 +62,6 @@ config UBSAN_SANITIZE_ALL config UBSAN_NO_ALIGNMENT bool "Disable checking of pointers alignment" - depends on UBSAN default y if HAVE_EFFICIENT_UNALIGNED_ACCESS help This option disables the check of unaligned memory accesses. @@ -57,7 +74,9 @@ config UBSAN_ALIGNMENT config TEST_UBSAN tristate "Module for testing for undefined behavior detection" - depends on m && UBSAN + depends on m help This is a test module for UBSAN. It triggers various undefined behavior, and detect it. + +endif # if UBSAN diff --git a/scripts/Makefile.ubsan b/scripts/Makefile.ubsan index 668a91510bfe..5b15bc425ec9 100644 --- a/scripts/Makefile.ubsan +++ b/scripts/Makefile.ubsan @@ -5,14 +5,19 @@ ifdef CONFIG_UBSAN_ALIGNMENT CFLAGS_UBSAN += $(call cc-option, -fsanitize=alignment) endif +ifdef CONFIG_UBSAN_BOUNDS + CFLAGS_UBSAN += $(call cc-option, -fsanitize=bounds) +endif + +ifdef CONFIG_UBSAN_MISC CFLAGS_UBSAN += $(call cc-option, -fsanitize=shift) CFLAGS_UBSAN += $(call cc-option, -fsanitize=integer-divide-by-zero) CFLAGS_UBSAN += $(call cc-option, -fsanitize=unreachable) CFLAGS_UBSAN += $(call cc-option, -fsanitize=signed-integer-overflow) - CFLAGS_UBSAN += $(call cc-option, -fsanitize=bounds) CFLAGS_UBSAN += $(call cc-option, -fsanitize=object-size) CFLAGS_UBSAN += $(call cc-option, -fsanitize=bool) CFLAGS_UBSAN += $(call cc-option, -fsanitize=enum) +endif ifdef CONFIG_UBSAN_TRAP CFLAGS_UBSAN += $(call cc-option, -fsanitize-undefined-trap-on-error) From patchwork Thu Feb 27 19:35:13 2020 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Kees Cook X-Patchwork-Id: 11409571 Return-Path: Received: from mail.kernel.org (pdx-korg-mail-1.web.codeaurora.org [172.30.200.123]) by pdx-korg-patchwork-2.web.codeaurora.org (Postfix) with ESMTP id 60E8B159A for ; Thu, 27 Feb 2020 19:36:12 +0000 (UTC) Received: from mother.openwall.net (mother.openwall.net [195.42.179.200]) by mail.kernel.org (Postfix) with SMTP id BD652222C2 for ; Thu, 27 Feb 2020 19:36:10 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (1024-bit key) header.d=chromium.org header.i=@chromium.org header.b="U18RVdaW" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org BD652222C2 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=chromium.org Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=kernel-hardening-return-17988-patchwork-kernel-hardening=patchwork.kernel.org@lists.openwall.com Received: (qmail 1859 invoked by uid 550); 27 Feb 2020 19:35:40 -0000 Mailing-List: contact kernel-hardening-help@lists.openwall.com; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-ID: Delivered-To: mailing list kernel-hardening@lists.openwall.com Received: (qmail 1760 invoked from network); 27 Feb 2020 19:35:37 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=chromium.org; s=google; h=from:to:cc:subject:date:message-id:in-reply-to:references :mime-version:content-transfer-encoding; bh=tZTI1WKOfKcUGuqkPLx5fh8/0duDs7Ezr+5qHoGz4tY=; b=U18RVdaWlP4fBhZgQ7gfvBZ661edo3X9oUFSv45hHr9vetX28ZNvck46LUZ1rbgFl7 CoC4XHpp5cC7LAS3bYtkiJL7toH48S68r6LeXzb4rPgznn2+AxmV9w7kxkJPj9fN2INY Amg3+QBFjZeomIWu5Uc7552gBpvlzUK6BPO/k= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:subject:date:message-id:in-reply-to :references:mime-version:content-transfer-encoding; bh=tZTI1WKOfKcUGuqkPLx5fh8/0duDs7Ezr+5qHoGz4tY=; b=MjDJbyWHSlrHD1rply1bi6OB6kM21OY7V8ERoBDQ7/B52kfqz2+84GzWKqfje8jwv5 /G8Xt58rwZg7zaJt2aQxQ4UlEhlI2JgGhgbRI+qX0kHkGpWn/Mr02Hd4cr6BK3uTsHAa rd6w88FZR+s+q+BG//N7jFz/0NTGbV7lLDUjX7LBcfdhp7m0lY3FTJ0ASTF+mnUbnzlX 5bwN6r7KcsK8Gs75QRyJCVGiBrgDRiKw1bOXzNdy5tVk7XIxZE8UF+MRAlP35CSA/rWG PUG8HV9wZlGJtgRWLwK9Uv0KXyJgbRwBBQt/Ode0N5XmATMRN3CTjkSCvb0mfWZXhx+H 1s4Q== X-Gm-Message-State: APjAAAV+G1R9PBgKFZRTXWC20ySjgAfwC/MqRetEk5hfQSss0+kCdHST VH0Qa2/sMNZTlzdI/v3E0D2vcA== X-Google-Smtp-Source: APXvYqxyCvij60VoJLTsJE+/xAjIsKAshftPcvHqagxU4eIhmZpMwxKx52I39qHK7Pkm7LLOl0iliA== X-Received: by 2002:a65:668c:: with SMTP id b12mr914117pgw.14.1582832125520; Thu, 27 Feb 2020 11:35:25 -0800 (PST) From: Kees Cook To: Andrew Morton Cc: Kees Cook , Dmitry Vyukov , Andrey Ryabinin , Elena Petrova , Andrey Konovalov , Alexander Potapenko , Dan Carpenter , "Gustavo A. R. Silva" , Arnd Bergmann , Ard Biesheuvel , kasan-dev@googlegroups.com, linux-mm@kvack.org, linux-kernel@vger.kernel.org, kernel-hardening@lists.openwall.com, syzkaller@googlegroups.com Subject: [PATCH v5 3/6] lkdtm/bugs: Add arithmetic overflow and array bounds checks Date: Thu, 27 Feb 2020 11:35:13 -0800 Message-Id: <20200227193516.32566-4-keescook@chromium.org> X-Mailer: git-send-email 2.20.1 In-Reply-To: <20200227193516.32566-1-keescook@chromium.org> References: <20200227193516.32566-1-keescook@chromium.org> MIME-Version: 1.0 Adds LKDTM tests for arithmetic overflow (both signed and unsigned), as well as array bounds checking. Signed-off-by: Kees Cook Acked-by: Dmitry Vyukov --- drivers/misc/lkdtm/bugs.c | 75 ++++++++++++++++++++++++++++++++++++++ drivers/misc/lkdtm/core.c | 3 ++ drivers/misc/lkdtm/lkdtm.h | 3 ++ 3 files changed, 81 insertions(+) diff --git a/drivers/misc/lkdtm/bugs.c b/drivers/misc/lkdtm/bugs.c index de87693cf557..e4c61ffea35c 100644 --- a/drivers/misc/lkdtm/bugs.c +++ b/drivers/misc/lkdtm/bugs.c @@ -11,6 +11,7 @@ #include #include #include +#include #ifdef CONFIG_X86_32 #include @@ -175,6 +176,80 @@ void lkdtm_HUNG_TASK(void) schedule(); } +volatile unsigned int huge = INT_MAX - 2; +volatile unsigned int ignored; + +void lkdtm_OVERFLOW_SIGNED(void) +{ + int value; + + value = huge; + pr_info("Normal signed addition ...\n"); + value += 1; + ignored = value; + + pr_info("Overflowing signed addition ...\n"); + value += 4; + ignored = value; +} + + +void lkdtm_OVERFLOW_UNSIGNED(void) +{ + unsigned int value; + + value = huge; + pr_info("Normal unsigned addition ...\n"); + value += 1; + ignored = value; + + pr_info("Overflowing unsigned addition ...\n"); + value += 4; + ignored = value; +} + +/* Intentially using old-style flex array definition of 1 byte. */ +struct array_bounds_flex_array { + int one; + int two; + char data[1]; +}; + +struct array_bounds { + int one; + int two; + char data[8]; + int three; +}; + +void lkdtm_ARRAY_BOUNDS(void) +{ + struct array_bounds_flex_array *not_checked; + struct array_bounds *checked; + volatile int i; + + not_checked = kmalloc(sizeof(*not_checked) * 2, GFP_KERNEL); + checked = kmalloc(sizeof(*checked) * 2, GFP_KERNEL); + + pr_info("Array access within bounds ...\n"); + /* For both, touch all bytes in the actual member size. */ + for (i = 0; i < sizeof(checked->data); i++) + checked->data[i] = 'A'; + /* + * For the uninstrumented flex array member, also touch 1 byte + * beyond to verify it is correctly uninstrumented. + */ + for (i = 0; i < sizeof(not_checked->data) + 1; i++) + not_checked->data[i] = 'A'; + + pr_info("Array access beyond bounds ...\n"); + for (i = 0; i < sizeof(checked->data) + 1; i++) + checked->data[i] = 'B'; + + kfree(not_checked); + kfree(checked); +} + void lkdtm_CORRUPT_LIST_ADD(void) { /* diff --git a/drivers/misc/lkdtm/core.c b/drivers/misc/lkdtm/core.c index ee0d6e721441..2e04719b503c 100644 --- a/drivers/misc/lkdtm/core.c +++ b/drivers/misc/lkdtm/core.c @@ -129,6 +129,9 @@ static const struct crashtype crashtypes[] = { CRASHTYPE(HARDLOCKUP), CRASHTYPE(SPINLOCKUP), CRASHTYPE(HUNG_TASK), + CRASHTYPE(OVERFLOW_SIGNED), + CRASHTYPE(OVERFLOW_UNSIGNED), + CRASHTYPE(ARRAY_BOUNDS), CRASHTYPE(EXEC_DATA), CRASHTYPE(EXEC_STACK), CRASHTYPE(EXEC_KMALLOC), diff --git a/drivers/misc/lkdtm/lkdtm.h b/drivers/misc/lkdtm/lkdtm.h index c56d23e37643..8391081c6f13 100644 --- a/drivers/misc/lkdtm/lkdtm.h +++ b/drivers/misc/lkdtm/lkdtm.h @@ -22,6 +22,9 @@ void lkdtm_SOFTLOCKUP(void); void lkdtm_HARDLOCKUP(void); void lkdtm_SPINLOCKUP(void); void lkdtm_HUNG_TASK(void); +void lkdtm_OVERFLOW_SIGNED(void); +void lkdtm_OVERFLOW_UNSIGNED(void); +void lkdtm_ARRAY_BOUNDS(void); void lkdtm_CORRUPT_LIST_ADD(void); void lkdtm_CORRUPT_LIST_DEL(void); void lkdtm_CORRUPT_USER_DS(void); From patchwork Thu Feb 27 19:35:14 2020 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Kees Cook X-Patchwork-Id: 11409561 Return-Path: Received: from mail.kernel.org (pdx-korg-mail-1.web.codeaurora.org [172.30.200.123]) by pdx-korg-patchwork-2.web.codeaurora.org (Postfix) with ESMTP id 24F8A14E3 for ; Thu, 27 Feb 2020 19:35:38 +0000 (UTC) Received: from mother.openwall.net (mother.openwall.net [195.42.179.200]) by mail.kernel.org (Postfix) with SMTP id 8097A24691 for ; Thu, 27 Feb 2020 19:35:37 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (1024-bit key) header.d=chromium.org header.i=@chromium.org header.b="g/0EvsSA" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 8097A24691 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=chromium.org Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=kernel-hardening-return-17984-patchwork-kernel-hardening=patchwork.kernel.org@lists.openwall.com Received: (qmail 1530 invoked by uid 550); 27 Feb 2020 19:35:34 -0000 Mailing-List: contact kernel-hardening-help@lists.openwall.com; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-ID: Delivered-To: mailing list kernel-hardening@lists.openwall.com Received: (qmail 1494 invoked from network); 27 Feb 2020 19:35:34 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=chromium.org; s=google; h=from:to:cc:subject:date:message-id:in-reply-to:references :mime-version:content-transfer-encoding; bh=46Z0N6nNFPIgM2OuwNgkHRjYe659IsqNoWw8FG0hdrY=; b=g/0EvsSAMFLQMs3F4fsuSd2nVZEd0UnWu4D3Sl3dqAK2cD5B2JP/5fjn+Xf0mTTCA1 5qBJKz6rexuU4wD/Fm2T6RKX1mqL5z11ejipV8pBRRNCR/z0fgr1nevk9cbdozCY3z4J CEEvmhdGXWUBzU64x5LbmMXX3iFxMU4Y/Igq8= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:subject:date:message-id:in-reply-to :references:mime-version:content-transfer-encoding; bh=46Z0N6nNFPIgM2OuwNgkHRjYe659IsqNoWw8FG0hdrY=; b=W0gdkrCx4BZw5nSjGDQmnuOjEkr1lMZOkqt894VXX1ZfChrelY3BxQ3lgK+tMNGIXu hVGewTt+5C+Jvxy+O+P8S2T0mS3mCW1I0aLwXsIloauO5lVLINVrPxjeYGekg+NtWj68 ka0q3n7fFGzMplNYOupMDkdsUEdhwFHEG1ltNRwhSyJqS3gvFp19NB2M5WQgrUKCedPM 4LQbt94w3WWm74FNSa3mt75V+lC9PC7ZscbVx6oEy8554ghPDN44KAn9yDCPW17rdhW8 0IsoUM2FH+iL7zMJau484V9iNt051847htemgTgV1qOEa2qivP4XklEVChoj+3yW6cl+ VHVA== X-Gm-Message-State: APjAAAW2ZBa90IwXIM8VMTNgHEy33TgmFMi/EmtoWgZUd/m+4II7f+Qj K0w2rpeTvH+mUjxWVkv8hOCMug== X-Google-Smtp-Source: APXvYqyO3xXE1iYRbSHC6/Q9hVVz43xR0biiVO0z4es+cZucLAEsJlQuw4NFe3BlB1tUhIBv2xxm2g== X-Received: by 2002:a17:90a:c24c:: with SMTP id d12mr520844pjx.113.1582832121953; Thu, 27 Feb 2020 11:35:21 -0800 (PST) From: Kees Cook To: Andrew Morton Cc: Kees Cook , Andrey Ryabinin , Elena Petrova , Andrey Konovalov , Alexander Potapenko , Dan Carpenter , "Gustavo A. R. Silva" , Arnd Bergmann , Ard Biesheuvel , kasan-dev@googlegroups.com, linux-mm@kvack.org, linux-kernel@vger.kernel.org, kernel-hardening@lists.openwall.com, syzkaller@googlegroups.com Subject: [PATCH v5 4/6] ubsan: Check panic_on_warn Date: Thu, 27 Feb 2020 11:35:14 -0800 Message-Id: <20200227193516.32566-5-keescook@chromium.org> X-Mailer: git-send-email 2.20.1 In-Reply-To: <20200227193516.32566-1-keescook@chromium.org> References: <20200227193516.32566-1-keescook@chromium.org> MIME-Version: 1.0 Syzkaller expects kernel warnings to panic when the panic_on_warn sysctl is set. More work is needed here to have UBSan reuse the WARN infrastructure, but for now, just check the flag manually. Link: https://lore.kernel.org/lkml/CACT4Y+bsLJ-wFx_TaXqax3JByUOWB3uk787LsyMVcfW6JzzGvg@mail.gmail.com Signed-off-by: Kees Cook --- lib/ubsan.c | 11 +++++++++++ 1 file changed, 11 insertions(+) diff --git a/lib/ubsan.c b/lib/ubsan.c index 7b9b58aee72c..429663eef6a7 100644 --- a/lib/ubsan.c +++ b/lib/ubsan.c @@ -156,6 +156,17 @@ static void ubsan_epilogue(void) "========================================\n"); current->in_ubsan--; + + if (panic_on_warn) { + /* + * This thread may hit another WARN() in the panic path. + * Resetting this prevents additional WARN() from panicking the + * system on this thread. Other threads are blocked by the + * panic_mutex in panic(). + */ + panic_on_warn = 0; + panic("panic_on_warn set ...\n"); + } } static void handle_overflow(struct overflow_data *data, void *lhs, From patchwork Thu Feb 27 19:35:15 2020 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Kees Cook X-Patchwork-Id: 11409573 Return-Path: Received: from mail.kernel.org (pdx-korg-mail-1.web.codeaurora.org [172.30.200.123]) by pdx-korg-patchwork-2.web.codeaurora.org (Postfix) with ESMTP id 502EC159A for ; Thu, 27 Feb 2020 19:36:20 +0000 (UTC) Received: from mother.openwall.net (mother.openwall.net [195.42.179.200]) by mail.kernel.org (Postfix) with SMTP id AC8EF2468E for ; Thu, 27 Feb 2020 19:36:19 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (1024-bit key) header.d=chromium.org header.i=@chromium.org header.b="YBkqK4RC" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org AC8EF2468E Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=chromium.org Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=kernel-hardening-return-17989-patchwork-kernel-hardening=patchwork.kernel.org@lists.openwall.com Received: (qmail 1958 invoked by uid 550); 27 Feb 2020 19:35:41 -0000 Mailing-List: contact kernel-hardening-help@lists.openwall.com; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-ID: Delivered-To: mailing list kernel-hardening@lists.openwall.com Received: (qmail 1871 invoked from network); 27 Feb 2020 19:35:40 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=chromium.org; s=google; h=from:to:cc:subject:date:message-id:in-reply-to:references :mime-version:content-transfer-encoding; bh=sVbVapbdvm9D9bZT8RLizJdch6+5SIEY/KYRYQVG8Tk=; b=YBkqK4RCOblb4V5cg2JjztQtg3wh+brHnQ/Xnw/4IBUFJRhh4GeFiQP9nVouaSw+sY Iq7R/urAShHZ7CPMQvKGeXyT+FOvmE0vy0gms+GZvnF1oUTIeAIqmZaTytVTOmRvhGYp 9u4+wigHHHW5WR6VelBYcFCmp7ofnwGN7wT7U= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:subject:date:message-id:in-reply-to :references:mime-version:content-transfer-encoding; bh=sVbVapbdvm9D9bZT8RLizJdch6+5SIEY/KYRYQVG8Tk=; b=QWocyYV5WNZXnSdYmN2PMcg9W8ly5MV7kQcND/bDqDCIRLBGhJoIhO69hc1M5WDgAl xCbTdYDvMDRwVDv3v9DzOhB4pBN91hkt1wOwObHZag8XdaX3+4SarDutoQhq4yfHt59E Cj3IcjMox/nHAtbrqobVoNJ5Q9EOnoSQ4w1Pe2vq/Aq4K4LmvT1YRphsg9zPbIdasqlP SZ/pLpmDQr9x+wfXeG9xHT9sk32G5dNyzxZo6rRo30p9ZZMbVFDEVcnw0BvfWGk3DEh5 8/q5zajP240r9vV8G8j5I1YyNUEjIc2Wopq47rm34P+t3Ip0yqVb6Jt5QsyLlveGb0Uy 7TJQ== X-Gm-Message-State: APjAAAX3Sm1zO4YrT+7FnZ91x97Bbl18cRYcNIsAri155q28Vl3ZZVfj YlyVeXncUVdAtGSBq0Hk99D7gw== X-Google-Smtp-Source: APXvYqwJAU0YQCF3NBelWYbAkfjhxYyfXVhFnc+XRJm1wrTo2TVo3yr52ImKKRO716VR/awYEpFPlg== X-Received: by 2002:a17:90a:3266:: with SMTP id k93mr527984pjb.23.1582832128663; Thu, 27 Feb 2020 11:35:28 -0800 (PST) From: Kees Cook To: Andrew Morton Cc: Kees Cook , Dmitry Vyukov , Andrey Ryabinin , Elena Petrova , Andrey Konovalov , Alexander Potapenko , Dan Carpenter , "Gustavo A. R. Silva" , Arnd Bergmann , Ard Biesheuvel , kasan-dev@googlegroups.com, linux-mm@kvack.org, linux-kernel@vger.kernel.org, kernel-hardening@lists.openwall.com, syzkaller@googlegroups.com Subject: [PATCH v5 5/6] kasan: Unset panic_on_warn before calling panic() Date: Thu, 27 Feb 2020 11:35:15 -0800 Message-Id: <20200227193516.32566-6-keescook@chromium.org> X-Mailer: git-send-email 2.20.1 In-Reply-To: <20200227193516.32566-1-keescook@chromium.org> References: <20200227193516.32566-1-keescook@chromium.org> MIME-Version: 1.0 As done in the full WARN() handler, panic_on_warn needs to be cleared before calling panic() to avoid recursive panics. Signed-off-by: Kees Cook Acked-by: Dmitry Vyukov --- mm/kasan/report.c | 10 +++++++++- 1 file changed, 9 insertions(+), 1 deletion(-) diff --git a/mm/kasan/report.c b/mm/kasan/report.c index 5ef9f24f566b..54bd98a1fc7b 100644 --- a/mm/kasan/report.c +++ b/mm/kasan/report.c @@ -92,8 +92,16 @@ static void end_report(unsigned long *flags) pr_err("==================================================================\n"); add_taint(TAINT_BAD_PAGE, LOCKDEP_NOW_UNRELIABLE); spin_unlock_irqrestore(&report_lock, *flags); - if (panic_on_warn) + if (panic_on_warn) { + /* + * This thread may hit another WARN() in the panic path. + * Resetting this prevents additional WARN() from panicking the + * system on this thread. Other threads are blocked by the + * panic_mutex in panic(). + */ + panic_on_warn = 0; panic("panic_on_warn set ...\n"); + } kasan_enable_current(); } From patchwork Thu Feb 27 19:35:16 2020 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Kees Cook X-Patchwork-Id: 11409575 Return-Path: Received: from mail.kernel.org (pdx-korg-mail-1.web.codeaurora.org [172.30.200.123]) by pdx-korg-patchwork-2.web.codeaurora.org (Postfix) with ESMTP id 4604614E3 for ; Thu, 27 Feb 2020 19:36:29 +0000 (UTC) Received: from mother.openwall.net (mother.openwall.net [195.42.179.200]) by mail.kernel.org (Postfix) with SMTP id 75F622468E for ; Thu, 27 Feb 2020 19:36:28 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (1024-bit key) header.d=chromium.org header.i=@chromium.org header.b="RHZfJ6Zj" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 75F622468E Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=chromium.org Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=kernel-hardening-return-17990-patchwork-kernel-hardening=patchwork.kernel.org@lists.openwall.com Received: (qmail 3131 invoked by uid 550); 27 Feb 2020 19:35:42 -0000 Mailing-List: contact kernel-hardening-help@lists.openwall.com; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-ID: Delivered-To: mailing list kernel-hardening@lists.openwall.com Received: (qmail 1915 invoked from network); 27 Feb 2020 19:35:41 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=chromium.org; s=google; h=from:to:cc:subject:date:message-id:in-reply-to:references :mime-version:content-transfer-encoding; bh=jDKV/BVhQvBMwfS/RHWg5/AFVijLTVXYoYGSEirzUqw=; b=RHZfJ6ZjFp5sp8ipveWK3eF5Dwye7KVaR6z9iE7vnbShK0NUzQN9/ddpgIgrsGsgEK go3dwiZKpqRZ3qYcFoaAv2UquFiu/gPa+ssqiHVgX5UpONSYMHpPyYe45+eKfCqoV6PD imMXzSGoEl4bONAdPTpTrri0RDknPx1NdKggU= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:subject:date:message-id:in-reply-to :references:mime-version:content-transfer-encoding; bh=jDKV/BVhQvBMwfS/RHWg5/AFVijLTVXYoYGSEirzUqw=; b=cwpxYfn0x1IK9lECnBdHoiA4PPNWfCGDaQa4/JNoVeAr5RpRFY5YOey/zcu8DI3ikn qAy94Jc0E4iZMpYD6wPqyR9MmI0y5pTAbwVBzIk0kOV5JTxR9sMWVSaN9RH0bYOiL852 GIHapPArrei5dDV6GR9Pri5ta92GsDyImKBgFff+hP0s6ORoX924Roi1b32+LkM/88Bh WY6hP6FN4/9+kSYbWK4DixkhvPXJ1Y0JtuSJG/2OAXriO9rJkQ2/UX+FOBRQ8pevTtdH Kn1TmXuUxHJfBHbfwYxxudL7+mtL25RMuDcwkODVYkw8hTRZcNlqNfmn3ShXs+daxOlI XmNw== X-Gm-Message-State: APjAAAV4FLWU19ElALbzWNRZjpl/PI8g9dUO3vCFBTVDaDLGbaQnyD3q ksoKL9MS3sjHdXc3HflSA7/Zqw== X-Google-Smtp-Source: APXvYqyHeYlpEECGTPxzGxPWtF5ov215jrWWJl8MujEvBMWpkviZ0neOmsNjS1WOeToNJ2l0nbJvvA== X-Received: by 2002:a62:e80a:: with SMTP id c10mr518798pfi.129.1582832129371; Thu, 27 Feb 2020 11:35:29 -0800 (PST) From: Kees Cook To: Andrew Morton Cc: Kees Cook , Dmitry Vyukov , Andrey Ryabinin , Elena Petrova , Andrey Konovalov , Alexander Potapenko , Dan Carpenter , "Gustavo A. R. Silva" , Arnd Bergmann , Ard Biesheuvel , kasan-dev@googlegroups.com, linux-mm@kvack.org, linux-kernel@vger.kernel.org, kernel-hardening@lists.openwall.com, syzkaller@googlegroups.com Subject: [PATCH v5 6/6] ubsan: Include bug type in report header Date: Thu, 27 Feb 2020 11:35:16 -0800 Message-Id: <20200227193516.32566-7-keescook@chromium.org> X-Mailer: git-send-email 2.20.1 In-Reply-To: <20200227193516.32566-1-keescook@chromium.org> References: <20200227193516.32566-1-keescook@chromium.org> MIME-Version: 1.0 When syzbot tries to figure out how to deduplicate bug reports, it prefers seeing a hint about a specific bug type (we can do better than just "UBSAN"). This lifts the handler reason into the UBSAN report line that includes the file path that tripped a check. Unfortunately, UBSAN does not provide function names. Suggested-by: Dmitry Vyukov Link: https://lore.kernel.org/lkml/CACT4Y+bsLJ-wFx_TaXqax3JByUOWB3uk787LsyMVcfW6JzzGvg@mail.gmail.com Signed-off-by: Kees Cook Acked-by: Andrey Konovalov --- lib/ubsan.c | 36 +++++++++++++++--------------------- 1 file changed, 15 insertions(+), 21 deletions(-) diff --git a/lib/ubsan.c b/lib/ubsan.c index 429663eef6a7..f8c0ccf35f29 100644 --- a/lib/ubsan.c +++ b/lib/ubsan.c @@ -45,13 +45,6 @@ static bool was_reported(struct source_location *location) return test_and_set_bit(REPORTED_BIT, &location->reported); } -static void print_source_location(const char *prefix, - struct source_location *loc) -{ - pr_err("%s %s:%d:%d\n", prefix, loc->file_name, - loc->line & LINE_MASK, loc->column & COLUMN_MASK); -} - static bool suppress_report(struct source_location *loc) { return current->in_ubsan || was_reported(loc); @@ -140,13 +133,14 @@ static void val_to_string(char *str, size_t size, struct type_descriptor *type, } } -static void ubsan_prologue(struct source_location *location) +static void ubsan_prologue(struct source_location *loc, const char *reason) { current->in_ubsan++; pr_err("========================================" "========================================\n"); - print_source_location("UBSAN: Undefined behaviour in", location); + pr_err("UBSAN: %s in %s:%d:%d\n", reason, loc->file_name, + loc->line & LINE_MASK, loc->column & COLUMN_MASK); } static void ubsan_epilogue(void) @@ -180,12 +174,12 @@ static void handle_overflow(struct overflow_data *data, void *lhs, if (suppress_report(&data->location)) return; - ubsan_prologue(&data->location); + ubsan_prologue(&data->location, type_is_signed(type) ? + "signed-integer-overflow" : + "unsigned-integer-overflow"); val_to_string(lhs_val_str, sizeof(lhs_val_str), type, lhs); val_to_string(rhs_val_str, sizeof(rhs_val_str), type, rhs); - pr_err("%s integer overflow:\n", - type_is_signed(type) ? "signed" : "unsigned"); pr_err("%s %c %s cannot be represented in type %s\n", lhs_val_str, op, @@ -225,7 +219,7 @@ void __ubsan_handle_negate_overflow(struct overflow_data *data, if (suppress_report(&data->location)) return; - ubsan_prologue(&data->location); + ubsan_prologue(&data->location, "negation-overflow"); val_to_string(old_val_str, sizeof(old_val_str), data->type, old_val); @@ -245,7 +239,7 @@ void __ubsan_handle_divrem_overflow(struct overflow_data *data, if (suppress_report(&data->location)) return; - ubsan_prologue(&data->location); + ubsan_prologue(&data->location, "division-overflow"); val_to_string(rhs_val_str, sizeof(rhs_val_str), data->type, rhs); @@ -264,7 +258,7 @@ static void handle_null_ptr_deref(struct type_mismatch_data_common *data) if (suppress_report(data->location)) return; - ubsan_prologue(data->location); + ubsan_prologue(data->location, "null-ptr-deref"); pr_err("%s null pointer of type %s\n", type_check_kinds[data->type_check_kind], @@ -279,7 +273,7 @@ static void handle_misaligned_access(struct type_mismatch_data_common *data, if (suppress_report(data->location)) return; - ubsan_prologue(data->location); + ubsan_prologue(data->location, "misaligned-access"); pr_err("%s misaligned address %p for type %s\n", type_check_kinds[data->type_check_kind], @@ -295,7 +289,7 @@ static void handle_object_size_mismatch(struct type_mismatch_data_common *data, if (suppress_report(data->location)) return; - ubsan_prologue(data->location); + ubsan_prologue(data->location, "object-size-mismatch"); pr_err("%s address %p with insufficient space\n", type_check_kinds[data->type_check_kind], (void *) ptr); @@ -354,7 +348,7 @@ void __ubsan_handle_out_of_bounds(struct out_of_bounds_data *data, void *index) if (suppress_report(&data->location)) return; - ubsan_prologue(&data->location); + ubsan_prologue(&data->location, "array-index-out-of-bounds"); val_to_string(index_str, sizeof(index_str), data->index_type, index); pr_err("index %s is out of range for type %s\n", index_str, @@ -375,7 +369,7 @@ void __ubsan_handle_shift_out_of_bounds(struct shift_out_of_bounds_data *data, if (suppress_report(&data->location)) goto out; - ubsan_prologue(&data->location); + ubsan_prologue(&data->location, "shift-out-of-bounds"); val_to_string(rhs_str, sizeof(rhs_str), rhs_type, rhs); val_to_string(lhs_str, sizeof(lhs_str), lhs_type, lhs); @@ -407,7 +401,7 @@ EXPORT_SYMBOL(__ubsan_handle_shift_out_of_bounds); void __ubsan_handle_builtin_unreachable(struct unreachable_data *data) { - ubsan_prologue(&data->location); + ubsan_prologue(&data->location, "unreachable"); pr_err("calling __builtin_unreachable()\n"); ubsan_epilogue(); panic("can't return from __builtin_unreachable()"); @@ -422,7 +416,7 @@ void __ubsan_handle_load_invalid_value(struct invalid_value_data *data, if (suppress_report(&data->location)) return; - ubsan_prologue(&data->location); + ubsan_prologue(&data->location, "invalid-load"); val_to_string(val_str, sizeof(val_str), data->type, val);