On Mon, Mar 10, 2025 at 05:37:50PM +0000, Catalin Marinas wrote:
On Fri, Mar 07, 2025 at 07:36:31PM -0800, Kees Cook wrote:
On Fri, Mar 07, 2025 at 06:33:13PM -0800, Peter Collingbourne wrote:
The optimized strscpy() and dentry_string_cmp() routines will read 8 unaligned bytes at a time via the function read_word_at_a_time(), but this is incompatible with MTE which will fault on a partially invalid read. The attributes on read_word_at_a_time() that disable KASAN are invisible to the CPU so they have no effect on MTE. Let's fix the bug for now by disabling the optimizations if the kernel is built with HW tag-based KASAN and consider improvements for followup changes.
Why is faulting on a partially invalid read a problem? It's still invalid, so ... it should fault, yes? What am I missing?
read_word_at_a_time() is used to read 8 bytes, potentially unaligned and beyond the end of string. The has_zero() function is then used to check where the string ends. For this uses, I think we can go with load_unaligned_zeropad() which handles a potential fault and pads the rest with zeroes.
Agh, right, I keep forgetting that this can read past the end of the actual allocation. I'd agree, load_unaligned_zeropad() makes sense there.
Signed-off-by: Peter Collingbourne pcc@google.com Link: https://linux-review.googlesource.com/id/If4b22e43b5a4ca49726b4bf98ada827fdf... Fixes: 94ab5b61ee16 ("kasan, arm64: enable CONFIG_KASAN_HW_TAGS") Cc: stable@vger.kernel.org
fs/dcache.c | 2 +- lib/string.c | 3 ++- 2 files changed, 3 insertions(+), 2 deletions(-)
Why are DCACHE_WORD_ACCESS and HAVE_EFFICIENT_UNALIGNED_ACCESS separate things? I can see at least one place where it's directly tied:
arch/arm/Kconfig:58: select DCACHE_WORD_ACCESS if HAVE_EFFICIENT_UNALIGNED_ACCESS
DCACHE_WORD_ACCESS requires load_unaligned_zeropad() which handles the faults. For some reason, read_word_at_a_time() doesn't expect to fault and it is only used with HAVE_EFFICIENT_UNALIGNED_ACCESS. I guess arm32 only enabled load_unaligned_zeropad() on hardware that supports efficient unaligned accesses (v6 onwards), hence the dependency.
Would it make sense to sort this out so that KASAN_HW_TAGS can be taken into account at the Kconfig level instead?
I don't think we should play with config options but rather sort out the fault path (load_unaligned_zeropad) or disable MTE temporarily. I'd go with the former as long as read_word_at_a_time() is only used for strings in conjunction with has_zero(). I haven't checked.
Okay, sounds good. (And with a mild thread-merge: yes, folks want to use KASAN_HW_TAGS=y in production.)