[PATCH] KMSAN: fix memset() when using fortify-source, again

[PATCH] KMSAN: fix memset() when using fortify-source, again

[Arnd Bergmann]

From: Arnd Bergmann <arnd@arndb.de>

Both kmsan and fortify-source replace the memset function. When both
are enabled at the same time, the kmsan version gets used, which triggers
a warning about fortify-source being nonfunctional:

warning: unsafe memset() usage lacked '__write_overflow' symbol in /home/arnd/arm-soc/lib/test_fortify/write_overflow-memset.c
warning: unsafe memset() usage lacked '__write_overflow_field' symbol in /home/arnd/arm-soc/lib/test_fortify/write_overflow_field-memset.c

Commit 78a498c3a227 already tried to address this, but this seems
to only have worked for memcpy() and memmove() but not memset(),
which is still lacking the macro definition when KMSAN is enabled.

Remove the incorrect #ifndef check around the memset() macro.

Fixes: ff901d80fff6 ("x86: kmsan: use __msan_ string functions where possible.")
Fixes: 78a498c3a227 ("x86: fortify: kmsan: fix KMSAN fortify builds")
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
---
The patch passes randconfig builds on x86/arm/arm64/s390 for me,
but please double-check all the corner cases, as it's still
possible that the #ifndef is required to work around a runtime
issue that I did not test.
---
 include/linux/fortify-string.h | 2 --
 1 file changed, 2 deletions(-)

diff --git a/include/linux/fortify-string.h b/include/linux/fortify-string.h
index 5541c75ab852..5eddaefc61bd 100644
--- a/include/linux/fortify-string.h
+++ b/include/linux/fortify-string.h
@@ -506,10 +506,8 @@ __FORTIFY_INLINE bool fortify_memset_chk(__kernel_size_t size,
  * __struct_size() vs __member_size() must be captured here to avoid
  * evaluating argument side-effects further into the macro layers.
  */
-#ifndef CONFIG_KMSAN
 #define memset(p, c, s) __fortify_memset_chk(p, c, s,			\
 		__struct_size(p), __member_size(p))
-#endif
 
 /*
  * To make sure the compiler can enforce protection against buffer overflows,
-- 
2.39.5

Re: [PATCH] KMSAN: fix memset() when using fortify-source, again

[Kees Cook]

On Thu, Jun 18, 2026 at 04:29:43PM +0200, Arnd Bergmann wrote:
> From: Arnd Bergmann <arnd@arndb.de>
> 
> Both kmsan and fortify-source replace the memset function. When both
> are enabled at the same time, the kmsan version gets used, which triggers
> a warning about fortify-source being nonfunctional:
> 
> warning: unsafe memset() usage lacked '__write_overflow' symbol in /home/arnd/arm-soc/lib/test_fortify/write_overflow-memset.c
> warning: unsafe memset() usage lacked '__write_overflow_field' symbol in /home/arnd/arm-soc/lib/test_fortify/write_overflow_field-memset.c
> 
> Commit 78a498c3a227 already tried to address this, but this seems
> to only have worked for memcpy() and memmove() but not memset(),
> which is still lacking the macro definition when KMSAN is enabled.
> 
> Remove the incorrect #ifndef check around the memset() macro.

Ah, nice find.

> 
> Fixes: ff901d80fff6 ("x86: kmsan: use __msan_ string functions where possible.")
> Fixes: 78a498c3a227 ("x86: fortify: kmsan: fix KMSAN fortify builds")
> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
> ---
> The patch passes randconfig builds on x86/arm/arm64/s390 for me,
> but please double-check all the corner cases, as it's still
> possible that the #ifndef is required to work around a runtime
> issue that I did not test.

How about I drop this into -next right after -rc2 and we can see what
falls out of it?

-Kees

-- 
Kees Cook

Re: [PATCH] KMSAN: fix memset() when using fortify-source, again

[Arnd Bergmann]

On Fri, Jun 19, 2026, at 05:55, Kees Cook wrote:
> On Thu, Jun 18, 2026 at 04:29:43PM +0200, Arnd Bergmann wrote:
>> Fixes: ff901d80fff6 ("x86: kmsan: use __msan_ string functions where possible.")
>> Fixes: 78a498c3a227 ("x86: fortify: kmsan: fix KMSAN fortify builds")
>> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
>> ---
>> The patch passes randconfig builds on x86/arm/arm64/s390 for me,
>> but please double-check all the corner cases, as it's still
>> possible that the #ifndef is required to work around a runtime
>> issue that I did not test.
>
> How about I drop this into -next right after -rc2 and we can see what
> falls out of it?

Sounds good, thanks!

     Arnd