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

From: Andrey Ryabinin

Date: Fri Mar 06 2026 - 14:26:10 EST


Arnd Bergmann <arnd@xxxxxxxxxx> writes:

> From: Arnd Bergmann <arnd@xxxxxxxx>
>
> 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@xxxxxxxxxx>
> Cc: Marco Elver <elver@xxxxxxxxxx>
> Cc: Andrey Konovalov <andreyknvl@xxxxxxxxx>
> Cc: Andrey Ryabinin <ryabinin.a.a@xxxxxxxxx>
> Cc: kasan-dev@xxxxxxxxxxxxxxxx
> Cc: linux-hardening@xxxxxxxxxxxxxxx
> Signed-off-by: Arnd Bergmann <arnd@xxxxxxxx>
> ---
> lib/Makefile | 1 +
> 1 file changed, 1 insertion(+)
>

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