Re: [PATCH v2] string: copy byte by byte in sized_strscpy() under KASAN

[Andrey Ryabinin]

Qiliang Yuan <odys.yuan@xxxxxxxxx> writes:

> sized_strscpy() copies a word at a time. The loads go through
> read_word_at_a_time(), which checks the first byte of each word with
> KASAN, or through load_unaligned_zeropad() on architectures with
> CONFIG_DCACHE_WORD_ACCESS. Under KMSAN it copies byte by byte instead.
>
> load_unaligned_zeropad() is inline assembly that the compiler does not
> instrument. Since sized_strscpy() switched to it, generic and software
> tag-based KASAN no longer report strscpy() reading from a freed or
> out-of-bounds source on x86_64, arm64 and the other architectures that
> select CONFIG_DCACHE_WORD_ACCESS. On x86_64 the kasan_strings KUnit
> case, which expects a report when the first source byte is out of
> bounds, fails as a result:
>
>   KASAN and string KUnit suites      failures
>   on x86_64, generic KASAN        before    after
>   CONFIG_FORTIFY_SOURCE=n              1        0
>   CONFIG_FORTIFY_SOURCE=y              1        0
>
> Copy byte by byte under generic and software tag-based KASAN too, as
> under KMSAN, so that every byte strscpy() reads is checked. Hardware
> tag-based KASAN keeps the word loop that load_unaligned_zeropad() was
> brought in for.
>
> Fixes: d94c12bd97d5 ("string: Add load_unaligned_zeropad() code path to sized_strscpy()")
> Suggested-by: Andrew Morton <akpm@xxxxxxxxxxxxxxxxxxxx>
> Signed-off-by: Qiliang Yuan <odys.yuan@xxxxxxxxx>
> ---
> V1 -> V2:
> - Copy byte by byte under generic and software tag-based KASAN instead
>   of checking the first byte of each word (Andrew Morton)
> - Rebase onto v7.3
>
> v1: https://lore.kernel.org/r/20261018-bug-string-strscpy-kasan-first-byte-v1-1-375a2c46d88f@xxxxxxxxx
>
> The other callers of load_unaligned_zeropad() are covered by a separate
> series (Peter Collingbourne):
> https://lore.kernel.org/r/20261019-bug-word-at-a-time-zeropad-kasan-v1-0-f21a3ed6a477@xxxxxxxxx
> ---
>  lib/string.c | 8 +++++++-
>  1 file changed, 7 insertions(+), 1 deletion(-)
>
> diff --git a/lib/string.c b/lib/string.c
> index a3778d5aab4af..d14e42ae3903b 100644
> --- a/lib/string.c
> +++ b/lib/string.c
> @@ -124,8 +124,14 @@ ssize_t sized_strscpy(char *dest, const char *src, size_t count)
>  	 * uninitialized bytes after the trailing zero and use them in
>  	 * comparisons. Disable this optimization under KMSAN to prevent
>  	 * false positive reports.
> +	 *
> +	 * KASAN does not see load_unaligned_zeropad() at all, and
> +	 * read_word_at_a_time() only checks the first byte of each word.
> +	 * Disable it under software KASAN as well, so that every byte read
> +	 * is checked.
>  	 */
> -	if (IS_ENABLED(CONFIG_KMSAN))
> +	if (IS_ENABLED(CONFIG_KMSAN) || IS_ENABLED(CONFIG_KASAN_GENERIC) ||
> +	    IS_ENABLED(CONFIG_KASAN_SW_TAGS))
>  		max = 0;

I think this has been discussed before several times.
The rationale for introducing read_word_at_a_time() with a first-byte check was
to preserve the word-at-a-time implementation while allowing KASAN to check the
access.

We should avoid changing semantics or implementation under KASAN unless
absolutely necessary. Changing the implementation specifically for KASAN means
we test a different code path from the one used in production. That defeats
part of the purpose of testing the kernel with KASAN.

The only missing piece here is the equivalent first-byte check in
load_unaligned_zeropad(). So the proposed instrumentation series [1] is the
right way to fix this.

[1] https://lore.kernel.org/r/20261019-bug-word-at-a-time-zeropad-kasan-v1-0-f21a3ed6a477@xxxxxxxxx