From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id 47AE2C982C1 for ; Thu, 17 Sep 2026 02:31:34 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20210309; h=Sender:List-Subscribe:List-Help :List-Post:List-Archive:List-Unsubscribe:List-Id:Content-Type: Content-Transfer-Encoding:MIME-Version:References:In-Reply-To:Message-ID:Date :Subject:CC:To:From:Reply-To:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Owner; bh=aXF6YrgcgA4YTuuysGFgLRiru7/qN9xHp9WtTJJgMfI=; b=rxvTzsUljIq0T4eG9YTAZegQp/ hDG+bQ5oLk2ZQLMTqd9KkEzIE1tHrdw+xK2wx/Ciy5BFRJSUiWXU2SRXy7Tzpwqfdu5jqF2ZHnwe9 YMWL4yQEweBRbWi/T334aO90fNyYyihUM4f0J/lQkCOiFxwUJSJggJOlZ0XNzh5Wft0f0q9OLk4S9 oAv3YwjoYSgh4jElaSOBm8RFLF95WIAqy17tHCI/kn/S7gjpWfQvvnmYnEv0qIte47/u1q6OcraO8 xtARmwj7Bg0djfEKKdRGou4LtYBYIwvp1O5nPBJj8PIJwxVUvWpyRYXnQmNU/c3oQcmWGZeqeG4dK 7b8G0k7Q==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.99.1 #2 (Red Hat Linux)) id 1x71uJ-0000000AT1Q-089h; Thu, 17 Sep 2026 02:31:27 +0000 Received: from canpmsgout10.his.huawei.com ([113.46.200.225]) by bombadil.infradead.org with esmtps (Exim 4.99.1 #2 (Red Hat Linux)) id 1x71uA-0000000ASyK-0Rzv for linux-arm-kernel@lists.infradead.org; Thu, 17 Sep 2026 02:31:20 +0000 dkim-signature: v=1; a=rsa-sha256; d=huawei.com; s=dkim; c=relaxed/relaxed; q=dns/txt; h=From; bh=aXF6YrgcgA4YTuuysGFgLRiru7/qN9xHp9WtTJJgMfI=; b=Wbc9QZ4QA1NKRWSOppyIC28YevU232aoPazyaoqpNrEPW6ujwe8OWriWm/RU7pRCUHhCnAnYY +LQLo3bBpoDeRUjrKH1N4ttXPq4TYflEDNU8FMzUYs0FKvNXAY1xHXEyiw7KxF3NGbMOp1X4jr2 oLmFqaeAwMWMxsJmR5cZMJ0= Received: from mail.maildlp.com (unknown [172.19.162.92]) by canpmsgout10.his.huawei.com (SkyGuard) with ESMTPS id 4hlfbw6kzVz1K96s; Thu, 17 Sep 2026 10:20:12 +0800 (CST) Received: from kwepemk300012.china.huawei.com (unknown [7.202.194.175]) by mail.maildlp.com (Postfix) with ESMTPS id 3AD3540565; Thu, 17 Sep 2026 10:31:12 +0800 (CST) Received: from DESKTOP-A37P9LK.huawei.com (10.67.109.17) by kwepemk300012.china.huawei.com (7.202.194.175) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.2562.45; Thu, 17 Sep 2026 10:31:11 +0800 From: Xie Yuanbin To: , , , , , , , , , , , , CC: , , , , , , , Xie Yuanbin Subject: [PATCH v2 5.10.y/5.15.y 1/3] ARM: fix hash_name() fault Date: Thu, 17 Sep 2026 10:30:54 +0800 Message-ID: <20260917023056.2280-2-xieyuanbin1@huawei.com> X-Mailer: git-send-email 2.55.0 In-Reply-To: <20260917023056.2280-1-xieyuanbin1@huawei.com> References: <20260917023056.2280-1-xieyuanbin1@huawei.com> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Content-Type: text/plain X-Originating-IP: [10.67.109.17] X-ClientProxiedBy: kwepems100002.china.huawei.com (7.221.188.206) To kwepemk300012.china.huawei.com (7.202.194.175) X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.9.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20260916_193119_382818_43E8F097 X-CRM114-Status: GOOD ( 22.97 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org From: "Russell King (Oracle)" [ Upstream commit 7733bc7d299d682f2723dc38fc7f370b9bf973e9 ] Zizhi Wo reports: "During the execution of hash_name()->load_unaligned_zeropad(), a potential memory access beyond the PAGE boundary may occur. For example, when the filename length is near the PAGE_SIZE boundary. This triggers a page fault, which leads to a call to do_page_fault()->mmap_read_trylock(). If we can't acquire the lock, we have to fall back to the mmap_read_lock() path, which calls might_sleep(). This breaks RCU semantics because path lookup occurs under an RCU read-side critical section." This is seen with CONFIG_DEBUG_ATOMIC_SLEEP=y and CONFIG_KFENCE=y. Kernel addresses (with the exception of the vectors/kuser helper page) do not have VMAs associated with them. If the vectors/kuser helper page faults, then there are two possibilities: 1. if the fault happened while in kernel mode, then we're basically dead, because the CPU won't be able to vector through this page to handle the fault. 2. if the fault happened while in user mode, that means the page was protected from user access, and we want to fault anyway. Thus, we can handle kernel addresses from any context entirely separately without going anywhere near the mmap lock. This gives us an entirely non-sleeping path for all kernel mode kernel address faults. As we handle the kernel address faults before interrupts are enabled, this change has the side effect of improving the branch predictor hardening, but does not completely solve the issue. [ Xie Yuanbin: At the upstream, the following patches are a patch set: 1. commit dea20281ac8822661576 ("ARM: group is_permission_fault() with is_translation_fault()") 2. commit 40b466db1dffb41f0529 ("ARM: allow __do_kernel_fault() to report execution of memory faults") 3. commit 7733bc7d299d682f2723 ("ARM: fix hash_name() fault") 4. commit fd2dee1c6e2256f726ba ("ARM: fix branch predictor hardening") patch 1. and 2. is unneeded for 5.10.y and 5.15.y . This patch backports patch 3. and simply adapts to the context differences. ] Reported-by: Zizhi Wo Reported-by: Xie Yuanbin Link: https://lore.kernel.org/r/20251126090505.3057219-1-wozizhi@huaweicloud.com Reviewed-by: Xie Yuanbin Tested-by: Xie Yuanbin Signed-off-by: Russell King (Oracle) Signed-off-by: Xie Yuanbin --- arch/arm/mm/fault.c | 35 +++++++++++++++++++++++++++++++++++ 1 file changed, 35 insertions(+) diff --git a/arch/arm/mm/fault.c b/arch/arm/mm/fault.c index c16d6a293b97..094137cd29c8 100644 --- a/arch/arm/mm/fault.c +++ b/arch/arm/mm/fault.c @@ -247,6 +247,35 @@ __do_page_fault(struct mm_struct *mm, unsigned long addr, unsigned int fsr, return fault; } +static int __kprobes +do_kernel_address_page_fault(struct mm_struct *mm, unsigned long addr, + unsigned int fsr, struct pt_regs *regs) +{ + if (user_mode(regs)) { + /* + * Fault from user mode for a kernel space address. User mode + * should not be faulting in kernel space, which includes the + * vector/khelper page. Send a SIGSEGV. + */ + __do_user_fault(addr, fsr, SIGSEGV, SEGV_MAPERR, regs); + } else { + /* + * Fault from kernel mode. Enable interrupts if they were + * enabled in the parent context. Section (upper page table) + * translation faults are handled via do_translation_fault(), + * so we will only get here for a non-present kernel space + * PTE or PTE permission fault. This may happen in exceptional + * circumstances and need the fixup tables to be walked. + */ + if (interrupts_enabled(regs)) + local_irq_enable(); + + __do_kernel_fault(mm, addr, fsr, regs); + } + + return 0; +} + static int __kprobes do_page_fault(unsigned long addr, unsigned int fsr, struct pt_regs *regs) { @@ -261,6 +290,12 @@ do_page_fault(unsigned long addr, unsigned int fsr, struct pt_regs *regs) tsk = current; mm = tsk->mm; + /* + * Handle kernel addresses faults separately, which avoids touching + * the mmap lock from contexts that are not able to sleep. + */ + if (addr >= TASK_SIZE) + return do_kernel_address_page_fault(mm, addr, fsr, regs); /* Enable interrupts if they were enabled in the parent context. */ if (interrupts_enabled(regs)) -- 2.55.0