From: Arnd Bergmann <[email protected]> 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 <[email protected]> Cc: Marco Elver <[email protected]> Cc: Andrey Konovalov <[email protected]> Cc: Andrey Ryabinin <[email protected]> Cc: [email protected] Cc: [email protected] Signed-off-by: Arnd Bergmann <[email protected]> --- 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
