Re: [PATCH v3 1/2] ARM: mm: fix use-after-free in __do_user_fault() under CONFIG_DEBUG_USER

[Lorenzo Stoakes <ljs@kernel.org>]

On Sat, Jul 11, 2026 at 03:56:51PM +0800, Xie Yuanbin wrote:
> On Sat, 11 Jul 2026 08:27:23 +0100, Lorenzo Stoakes wrote:
> > In general yeah but with mmap_write_trylock() after you add the attached
> > patch to a series (making sure to cc- the right people etc.)... but also,
> > wouldn't you just generally want this in show_pte()?
> >
> > Seems to me best way is to put the existing show_pte() into a __show_pte()
> > and then do show_pte() like (untested top of my head thing):
> >
> > void show_pte(const char *lvl, struct mm_struct *mm, unsigned long addr,
> > 	      bool is_user)
> > {
> > 	/* Write lock needed to account for concurrent downgraded munmap(). */
> > 	if (is_user && !mmap_write_trylock(mm)) {
> > 		printk("%s[%08lx] unable to acquire lock for PTE output\n",
> > 			lvl, addr);
> > 		return;
> > 	}
> > 	__show_pte(lvl, mm, addr);
> > 	if (is_user)
> > 		mmap_write_unlock(mm);
> > }
>
> For user faults, I think we don't need to worry about deadlock issues.
>
> As Russell King described, deadlock problems can only occur in kernel faults.
> On Tue, 7 Jul 2026 16:34:21 +0100, Russell King wrote:
> > Unconditionally taking the lock could lead to a deadlock. Consider
> > the case where the mmap lock is held, and we get an unrecognised
> > abort from the kernel.
>
> As we never return to user mode with mmap lock held, so for user faults,
> it is safe to acquire mmap lock. This is just the same with the syscall
> entry of `pkey_alloc`, we immediately acquire the mmap write lock:
> Link: https://elixir.bootlin.com/linux/v7.2-rc2/source/mm/mprotect.c#L1011
>
> For the kernel, the user faults entry and the system call entry are not
> fundamentally different; they are both kernel entry points.

OK given arm32 can't do any of the stuff that makes kernel faults an issue, and
if it's certain you can't deadlock on mmap write lock for VMA or non-VMA ranges
on user fault, then no need for the mmap write trylock, and just take the mmap
write lock unconditionally for user faults, and no lock for kernel faults I
guess?