[PATCH v4] ARM: mm: acquire mmap write lock around show_pte() for user faults

Linus Walleij linusw at kernel.org
Fri Jul 24 15:05:58 PDT 2026


On Thu, Jul 16, 2026 at 3:42 AM Xie Yuanbin <xieyuanbin1 at huawei.com> wrote:

> When CONFIG_DEBUG_USER=y, and cmdline "user_debug=31" is set,
> a user fault may trigger show_pte() without any lock.
> If another thread in the same process concurrently calls munmap(),
> the page table pages may be freed while show_pte() is still traversing
> them, causing a use-after-free in show_pte().
>
> If CONFIG_ARM_LPAE=y, this may cause a kernel panic if the pages table
> of PMD are freed when show_pte() is running.
>
> Acquire mmap_write_lock() around show_pte() for user faults to fix the
> contention.
>
> For user faults, additionally restrict that show_pte() is called only
> when the addr is a user-space address (addr < TASK_SIZE). This is because
> the lock of tsk->mm only protects the virtual memory of user address space,
> furthermore, dumping the page tables of a kernel-space address for user
> faults is unnecessary and may have security implications.
>
> Keep everything unchanged for kernel faults, because the kernel is
> already in the "oops" state, acquiring a lock may risk a deadlock.
>
> Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2")
> Fixes: 6d021b724481 ("ARM: dump pgd, pmd and pte states on unhandled data abort faults")
> Depends-on: <20260629123349.134224-1-xieyuanbin1 at huawei.com>
> Depends-on: 59e4f3b45b96 ("ARM: ensure interrupts are enabled in __do_user_fault()")

This looks a bit odd. I don't get the first fix tag, drop it.
I think drop both Depends-on as well.

> Cc: Russell King <linux at armlinux.org.uk>
> Suggested-by: Lorenzo Stoakes <ljs at kernel.org>
> Co-developed-by: Qi Xi <xiqi2 at huawei.com>
> Signed-off-by: Qi Xi <xiqi2 at huawei.com>
> Signed-off-by: Xie Yuanbin <xieyuanbin1 at huawei.com>

Looks correct to me otherwise.

Reviewed-by: Linus Walleij <linusw at kernel.org>

Put it in Russell's patch tracker after dropping the weird
tags.

Yours,
Linus Walleij



More information about the linux-arm-kernel mailing list