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

[Russell King <linux@armlinux.org.uk>]

On Fri, Jun 26, 2026 at 03:30:47PM +0800, Qi Xi wrote:
> When CONFIG_DEBUG_USER is enabled with user_debug=31 on 32-bit ARM,
> a user page fault triggers show_pte() via __do_user_fault() after
> do_page_fault() has already released mmap_read_lock. If another
> thread concurrently calls munmap(), the page table pages can be
> freed while show_pte() is still reading them, causing a
> use-after-free in show_pte().
> 
> The race can be reproduced on multi_v7_defconfig with:
>     CONFIG_DEBUG_USER=y
>     CONFIG_ARM_LPAE=y
>     kernel command line: user_debug=31
> 
> A delay inserted in show_pte() for testing widens the race window and
> makes the UAF reliably reproducible. On LPAE, the race works as
> follows:
> 
>   CPU 0 (fault path)                       CPU 1 (munmap)
>   munmap(page 0) -> clears PTE[0]
>   PTE/PMD pages remain
> 
>   read page 0 -> page fault
>     -> do_DataAbort()
>       -> do_page_fault()
>         -> lock_mm_and_find_vma() -> no VMA
>            (mmap_read_lock released)
>         -> __do_user_fault()
>           -> show_pte(tsk->mm, addr)
>             -> *pgd (valid)
>             -> p4d/pud checks pass
> 
>             -> [delay]                     munmap(page 1)
>                                              -> clears PTE[1]
>                                              -> PTE/PMD pages freed
>                                              -> PGD cleared
> 
>             -> pmd_offset(pud, addr)
>               -> *pud=0 -> __va(0)
>               -> dereference
>               -> secondary data abort (kernel)
> 
> Fix by taking mmap_read_lock() around show_pte() in __do_user_fault().
> __do_user_fault() is called from process context with interrupts
> enabled, so the context can sleep and mmap_read_lock() is safe here.

This is a fault path which should only be called when something is
already wrong, the mm lock may already be held (e.g. a kernel
fault while already holding the mmap lock.) We can't take any locks
here.

-- 
RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
FTTP is here! 80Mbps down 10Mbps up. Decent connectivity at last!