Arnd Bergmann <[email protected]> writes: > 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(+) >
Acked-by: Andrey Ryabinin <[email protected]>
