From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from canpmsgout02.his.huawei.com (canpmsgout02.his.huawei.com [113.46.200.217]) (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 1068E3E3DAB for ; Fri, 26 Jun 2026 07:45:14 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=113.46.200.217 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1782459918; cv=none; b=hNjqDiMuHJd2x4dSL/9MjAMq+p/O3HvNMKVlnBGXphfYYtRap+AAjj70a/2ib4n+E6mKKLGFOY6+jBxFebFqwIzKih2u6YT+WlrnV4ZT825h1e0mIco8N3G24FFJA72qUCVOdbrIZktrPoyAeDUMvb/Y2csIbjZn/XlXIwYURxg= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1782459918; c=relaxed/simple; bh=53QiXVyuD2kqGs85GUfTesos9/fPxUkC4VFSm5KL0v4=; h=From:To:CC:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version:Content-Type; b=phD3RVUZbDedzRVR4GAWl7UI5KHqUjMvGtB8yBf1KQxw3NLIQulQaL52kCJkyl35Qdvp+S5NgOdeX43RcYzNKlxweVeaB4jp07RWTNYCwiTxAYrZ4MD2QWOWAZIPIdNVElyeBMejIp+WbAMy2I8P+Vz45wJsdqgV9iue0hOxYzM= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=huawei.com; spf=pass smtp.mailfrom=huawei.com; dkim=pass (1024-bit key) header.d=huawei.com header.i=@huawei.com header.b=oGTAdcEI; arc=none smtp.client-ip=113.46.200.217 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=huawei.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=huawei.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=huawei.com header.i=@huawei.com header.b="oGTAdcEI" dkim-signature: v=1; a=rsa-sha256; d=huawei.com; s=dkim; c=relaxed/relaxed; q=dns/txt; h=From; bh=I+Uv0cdR6Pf4fklaZ04Ly+ptfQmm7jQs2VnfdYuLltw=; b=oGTAdcEICBAksGGu2Fm6Qo5SurU4/2RBMt7AI2cLPRvgVDbNtKXORcrimPfnx8D9YnYz5y/f1 GyJqQsaJ3s7dccDuWfNBoPCp01A24/c3J9FfsYOAEXQFsAVzophX/uCN/FLPWQU+9g9x9yUixEv uYmGi1uVcPsYylvmtvAwPKc= Received: from mail.maildlp.com (unknown [172.19.162.144]) by canpmsgout02.his.huawei.com (SkyGuard) with ESMTPS id 4gmnYC1KwjzcZyQ; Fri, 26 Jun 2026 15:36:31 +0800 (CST) Received: from kwepemo200010.china.huawei.com (unknown [7.202.195.178]) by mail.maildlp.com (Postfix) with ESMTPS id 434CC40538; Fri, 26 Jun 2026 15:45:12 +0800 (CST) Received: from huawei.com (10.44.142.85) by kwepemo200010.china.huawei.com (7.202.195.178) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.1544.36; Fri, 26 Jun 2026 15:45:11 +0800 From: Qi Xi To: Russell King , Andrew Morton CC: , , Yuanbin Xie , Nanyong Sun , Qi Xi Subject: [PATCH v3 1/2] ARM: mm: fix use-after-free in __do_user_fault() under CONFIG_DEBUG_USER Date: Fri, 26 Jun 2026 15:30:47 +0800 Message-ID: <20260626073048.3595106-2-xiqi2@huawei.com> X-Mailer: git-send-email 2.33.0 In-Reply-To: <20260626073048.3595106-1-xiqi2@huawei.com> References: <20260626073048.3595106-1-xiqi2@huawei.com> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Content-Type: text/plain X-ClientProxiedBy: kwepems100002.china.huawei.com (7.221.188.206) To kwepemo200010.china.huawei.com (7.202.195.178) 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. Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2") Tested-by: Yuanbin Xie Suggested-by: Yuanbin Xie Signed-off-by: Qi Xi --- arch/arm/mm/fault.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/arch/arm/mm/fault.c b/arch/arm/mm/fault.c index e62cc4be5a..1f2a85e1fa 100644 --- a/arch/arm/mm/fault.c +++ b/arch/arm/mm/fault.c @@ -181,7 +181,9 @@ __do_user_fault(unsigned long addr, unsigned int fsr, unsigned int sig, pr_err("8<--- cut here ---\n"); pr_err("%s: unhandled page fault (%d) at 0x%08lx, code 0x%03x\n", tsk->comm, sig, addr, fsr); + mmap_read_lock(tsk->mm); show_pte(KERN_ERR, tsk->mm, addr); + mmap_read_unlock(tsk->mm); show_regs(regs); } #endif -- 2.33.0