From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-alma10-1.taild15c8.ts.net [100.103.45.18]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id C7E0230E853 for ; Sat, 11 Jul 2026 06:43:51 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=100.103.45.18 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1783752232; cv=none; b=hyPcHyjdhprNRn4WGiZT7m60ZeKNMECJ6CVP9NkxWAD/KSvB8Yf/aWpdRdMS9l7hgtBQFhPd3EQ0yhscG1R1D7/D5f4Ysi3iKhr5qfldPB5kvNDMhdZrpkCgDjE1/4f+EyVKPQkTXaCDGgciRQzZGXuRA2MFnnTHcvaSorKgw24= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1783752232; c=relaxed/simple; bh=5xAgw03uj5cKLw6/54lKbco/b7cB3Scx5Mw/Z3AmSqg=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=H3c1ObIHleAdgmH+5ssd6eLRJGQr3DCI8F7y4zweBgSr/3fDTjuHqwB3O2+R8gehSZNj+4R5YDUNqWBNdfjydEGsgpln+/b6RZzwXyhoXjQ3bF1yGweRLuVTpeLPlit/glgRqTpRxr88W+3uRtdyvjtMCXX00gkcfwzwcKX6Yy0= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=kyjEDrRZ; arc=none smtp.client-ip=100.103.45.18 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="kyjEDrRZ" Received: by smtp.kernel.org (Postfix) with ESMTPSA id DAAD41F000E9; Sat, 11 Jul 2026 06:43:47 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kernel.org; s=k20260515; t=1783752231; bh=CucO9Dqyb3VrMc9+4nXcYsoF/W36DcjcAnqAMOVRe9s=; h=Date:From:To:Cc:Subject:References:In-Reply-To; b=kyjEDrRZbnsq6EmErAohHKx0a/rriFw3B5N1ibhCjSNx8H21OIRm+q3V900WWGh0l JqWTXxrqiX4dLNe8nf2dzEjpz6ZD85jh+ejyXbN3AdzGllPOCFmOQ6mStXGasDd57W fvgruQPeKnNXuG0IvvWCDMGGKlyv03JwfCTLtjnwN6TZwCKqr6vdJqHXt86/0cjUbW nbLvLdj/8P90vzMPDSKzMRv//E7aB8JELHDpxZtygvdcLTCB/s1/LOkBzMOYAQzBVp BWf8QSOKg57YH6S0MVIQ8OzpRWuXAHQCmQsmhKZIm6Uz3HyArtBPYjzUUbqNb9n5IW VcwPjp61e0vpg== Date: Sat, 11 Jul 2026 07:43:38 +0100 From: Lorenzo Stoakes To: Xie Yuanbin Cc: akpm@linux-foundation.org, david@kernel.org, liam@infradead.org, liaohua4@huawei.com, lilinjie8@huawei.com, linusw@kernel.org, linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org, linux-mm@kvack.org, linux@armlinux.org.uk, mhocko@suse.com, rppt@kernel.org, sunnanyong@huawei.com, surenb@google.com, vbabka@kernel.org, xiqi2@huawei.com Subject: Re: [PATCH v3 1/2] ARM: mm: fix use-after-free in __do_user_fault() under CONFIG_DEBUG_USER Message-ID: References: <20260707133527.81833-1-xieyuanbin1@huawei.com> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20260707133527.81833-1-xieyuanbin1@huawei.com> On Tue, Jul 07, 2026 at 09:35:27PM +0800, Xie Yuanbin wrote: > On Tue, 7 Jul 2026 13:46:19 +0100, Lorenzo Stoakes wrote: > > On Mon, Jul 06, 2026 at 09:32:47PM +0800, Xie Yuanbin wrote: > >> I have read this article: > >> Link: https://docs.kernel.org/mm/process_addrs.html > >> `mmap_read_lock(&init_mm)` should be able to ensure that the kernel > >> address's page tables can be traversed. But I'm not quite sure if > > > > I added a section specifically about this - > > > > https://docs.kernel.org/mm/process_addrs.html#traversing-non-vma-page-tables > > > > But note: > > > > "Since, aside from vmalloc and memory hot plug, kernel page tables are not torn > > down all that often - this usually suffices, however any caller of this > > functionality must ensure that any additionally required locks are acquired in > > advance." > > > > With the latter part being particularly important - you really need to be sure > > you aren't going to be raced on page table teardown by anything. > > > > However: > > > > * You're safe from vmalloc trying to install a huge page table (only way > > it removes intermediate page tables) since !HAVE_ARCH_HUGE_VMAP. > > > > * And since arm32 !ARCH_ENABLE_MEMORY_HOTPLUG you're safe from that too > > :) > > > > (Really I think you should be using walk_page_range_debug() here ultimately but > > that's a future refactor). > > > > BUT see below: > > > >> `mmap_read_lock(¤t->mm)` provides protection for user-space non-VMA > >> addresses? > > > > OK so this _does_ need addressing, and I covered it in the document: > > > > We also permit a truly unusual case is the traversal of non-VMA ranges > > in userland ranges, as provided for by walk_page_range_debug(). > > > > We must take great care in this case, as the munmap() implementation > > detaches VMAs under an mmap write lock before tearing down page tables > > under a downgraded mmap read lock. > > > > This means such an operation could race with this, and thus an mmap > > write lock is required. > > > > I.e. you need a write lock. > > Thank you very much for your reply. Now I fully understand: to traverse > the page tables of non-VMA addr in user address space, the mmap write > lock is required. You're welcome! :) > > But I still want like to ask a question: > > However: > > > > * You're safe from vmalloc trying to install a huge page table (only way > > it removes intermediate page tables) since !HAVE_ARCH_HUGE_VMAP. > > > > * And since arm32 !ARCH_ENABLE_MEMORY_HOTPLUG you're safe from that too > > :) > > If (just hypothetically), the ARM32 architecture supports huge pages > and memory hotplug, what kind of lock do I need to safely traverse the > page tables of non-VMA addr in kernel space? hotplug lock, mmap write lock. > > Thanks again. Cheers, Lorenzo