[PATCH] ubsan: turn off kmsan inside of ubsan instrumentation

[PATCH] ubsan: turn off kmsan inside of ubsan instrumentation

[Arnd Bergmann]

From: Arnd Bergmann <arnd@arndb.de>

The structure initialization in the two type mismatch handling functions
causes a call to __msan_memset() to be generated inside of a UACCESS
block, which in turn leads to an objtool warning about possibly leaking
uaccess-enabled state:

lib/ubsan.o: warning: objtool: __ubsan_handle_type_mismatch+0xda: call to __msan_memset() with UACCESS enabled
lib/ubsan.o: warning: objtool: __ubsan_handle_type_mismatch_v1+0xf4: call to __msan_memset() with UACCESS enabled

Most likely __msan_memset() is safe to be called here and could be added
to the uaccess_safe_builtin[] list of safe functions, but seeing that
the ubsan file itself already has kasan, ubsan and kcsan disabled itself,
it is probably a good idea to also turn off kmsan here, in particular this
also avoids the risk of recursing between ubsan and kcsan checks in
other functions of this file.

I saw this happen while testing randconfig builds with clang-22, but did
not try older versions, or attempt to see which kernel change introduced
the warning.

Cc: Kees Cook <kees@kernel.org>
Cc: Marco Elver <elver@google.com>
Cc: Andrey Konovalov <andreyknvl@gmail.com>
Cc: Andrey Ryabinin <ryabinin.a.a@gmail.com>
Cc: kasan-dev@googlegroups.com
Cc: linux-hardening@vger.kernel.org
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
---
 lib/Makefile | 1 +
 1 file changed, 1 insertion(+)

diff --git a/lib/Makefile b/lib/Makefile
index 280a71e4f813..3e1eeefd9832 100644
--- a/lib/Makefile
+++ b/lib/Makefile
@@ -306,6 +306,7 @@ obj-$(CONFIG_UBSAN) += ubsan.o
 UBSAN_SANITIZE_ubsan.o := n
 KASAN_SANITIZE_ubsan.o := n
 KCSAN_SANITIZE_ubsan.o := n
+KMSAN_SANITIZE_ubsan.o := n
 CFLAGS_ubsan.o := -fno-stack-protector $(DISABLE_KSTACK_ERASE)
 
 obj-$(CONFIG_SBITMAP) += sbitmap.o
-- 
2.39.5

Re: [PATCH] ubsan: turn off kmsan inside of ubsan instrumentation

[Andrey Ryabinin]

Arnd Bergmann <arnd@kernel.org> writes:

> From: Arnd Bergmann <arnd@arndb.de>
>
> The structure initialization in the two type mismatch handling functions
> causes a call to __msan_memset() to be generated inside of a UACCESS
> block, which in turn leads to an objtool warning about possibly leaking
> uaccess-enabled state:
>
> lib/ubsan.o: warning: objtool: __ubsan_handle_type_mismatch+0xda: call to __msan_memset() with UACCESS enabled
> lib/ubsan.o: warning: objtool: __ubsan_handle_type_mismatch_v1+0xf4: call to __msan_memset() with UACCESS enabled
>
> Most likely __msan_memset() is safe to be called here and could be added
> to the uaccess_safe_builtin[] list of safe functions, but seeing that
> the ubsan file itself already has kasan, ubsan and kcsan disabled itself,
> it is probably a good idea to also turn off kmsan here, in particular this
> also avoids the risk of recursing between ubsan and kcsan checks in
> other functions of this file.
>
> I saw this happen while testing randconfig builds with clang-22, but did
> not try older versions, or attempt to see which kernel change introduced
> the warning.
>
> Cc: Kees Cook <kees@kernel.org>
> Cc: Marco Elver <elver@google.com>
> Cc: Andrey Konovalov <andreyknvl@gmail.com>
> Cc: Andrey Ryabinin <ryabinin.a.a@gmail.com>
> Cc: kasan-dev@googlegroups.com
> Cc: linux-hardening@vger.kernel.org
> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
> ---
>  lib/Makefile | 1 +
>  1 file changed, 1 insertion(+)
>

Acked-by: Andrey Ryabinin <ryabinin.a.a@gmail.com>