Re: [PATCH v5 3/4] mm/kasan: Introduce helpers for lazy MMU mode sanitizer

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 3 potential issue(s) to consider:
- [Medium] The newly introduced KASAN PTE helpers lack `EXPORT_SYMBOL`, which will cause module build failures when utilized in inline page table accessors.
- [Medium] The generic `kasan_[un]poison_pte` API inherently conflicts with KASAN tracking requirements on architectures where `sizeof(pte_t) < KASAN_GRANULE_SIZE` (e.g., 32-bit architectures), causing WARN_ON splats and silent shadow memory corruption.
- [Medium] KASAN poisoning of PTEs during lazy MMU mode fundamentally breaks concurrent lockless PTE readers (e.g., GUP-fast), causing false-positive KASAN splats.
--

--- Patch [3]: [PATCH v5 3/4] mm/kasan: Introduce helpers for lazy MMU mode sanitizer ---
commit ad7a1a1292ef9676ee173915cfe50c0da8ea27a4
Author: Alexander Gordeev <agordeev@linux.ibm.com>

mm/kasan: Introduce helpers for lazy MMU mode sanitizer

This commit introduces KASAN helpers to allow architectures to catch
illegitimate direct PTE accesses while lazy MMU mode is enabled. It provides
kasan_poison_pte() and kasan_unpoison_pte() routines, along with a new
KASAN_LAZY_MMU_PTE shadow bug type.

> diff --git a/mm/kasan/common.c b/mm/kasan/common.c
> index b7d05c2a6d93d..cbf68680614e5 100644
> --- a/mm/kasan/common.c
> +++ b/mm/kasan/common.c
[ ... ]
> @@ -163,6 +163,16 @@ void __kasan_poison_slab(struct slab *slab)
>  		     KASAN_SLAB_REDZONE, false);
>  }
>  
> +void __kasan_poison_pte(pte_t *pte, int nr)
> +{
> +	kasan_poison(pte, sizeof(*pte) * nr, KASAN_LAZY_MMU_PTE, false);
> +}

[Severity: Medium]
Since lazy MMU mode is generally a per-thread or per-CPU state, but KASAN
shadow memory is a globally shared mapping, will poisoning a live PTE page
here trigger false-positive KASAN splats for concurrent legitimate lockless
page table walkers?

For instance, if get_user_pages_fast() or handle_pte_fault() executes a
READ_ONCE() on another CPU against this PTE, it seems they would hit the
globally poisoned shadow memory.

[Severity: Medium]
On 32-bit architectures where sizeof(pte_t) is 4 bytes, kasan_poison() will
receive a size of 4 when nr is 1.

Since generic KASAN enforces an 8-byte alignment constraint, will this trigger
the WARN_ON(size & KASAN_GRANULE_MASK) check?

[Severity: Medium]
If architectures call this helper from inline page table accessors like
ptep_get() or set_pte() in header files, will loadable modules fail to build
with undefined symbol errors?

It looks like this function and __kasan_unpoison_pte() are missing an
EXPORT_SYMBOL() or EXPORT_SYMBOL_GPL() declaration.

> +
> +void __kasan_unpoison_pte(pte_t *pte, int nr)
> +{
> +	kasan_unpoison(pte, sizeof(*pte) * nr, false);
> +}

[Severity: Medium]
kasan_unpoison() implicitly rounds the size up to the nearest
KASAN_GRANULE_SIZE, which is 8 bytes.

On 32-bit architectures with 4-byte PTEs, could unpoisoning a single PTE
inadvertently unpoison the adjacent PTE and corrupt its tracking state?

> +
>  void __kasan_unpoison_new_object(struct kmem_cache *cache, void *object)
>  {
>  	kasan_unpoison(object, cache->object_size, false);

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/cover.1783945507.git.agordeev@linux.ibm.com?part=3