Re: [RFC PATCH 1/4] mm: use proper PTE accessors in madvise() and mremap()

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [Critical] Calling `set_pte()` on an uninitialized stack variable causes undefined behavior, stack memory reads, and potential kernel panics.
--

--- Patch [1]: [RFC PATCH 1/4] mm: use proper PTE accessors in madvise() and mremap() ---
commit 75c34d0a3dcbb3f5f12f6bd64e11ac6572b6f8f8
Author: Alexander Gordeev <agordeev@linux.ibm.com>

mm: use proper PTE accessors in madvise() and mremap()

This commit converts direct page table entry pointer dereferences to use
the proper accessors in madvise() and mremap().

> diff --git a/mm/madvise.c b/mm/madvise.c
> index 07a21ca31bad4..77508ef1c1836 100644
> --- a/mm/madvise.c
> +++ b/mm/madvise.c
> @@ -1106,7 +1106,7 @@ static int guard_install_set_pte(unsigned long addr, unsigned long next,
>  	unsigned long *nr_pages = (unsigned long *)walk->private;
>  
>  	/* Simply install a PTE marker, this causes segfault on access. */
> -	*ptep = make_pte_marker(PTE_MARKER_GUARD);
> +	set_pte(ptep, make_pte_marker(PTE_MARKER_GUARD));

[Severity: Critical]
Is it safe to use set_pte() here?  In this code path, ptep is an out-parameter
pointing to an uninitialized stack variable rather than a live page table
entry.  This can be seen in the caller walk_pte_range_inner() in mm/pagewalk.c:

	pte_t new_pte;
	err = ops->install_pte(addr, addr + PAGE_SIZE, &new_pte, walk);

Because ptep points to the stack and not a live page table, this violates the
architectural API contracts of set_pte().  For example, on arm64, set_pte()
calls __ptep_get() which reads the uninitialized stack memory and passes it to
WARN_ON_ONCE(). On other architectures like Xen PV or PowerPC, set_pte() expects
a live page table mapping and can trigger hypercalls or specific cache flushes
using a stack address, potentially leading to crashes or unpredictable behavior.

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