From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from canpmsgout06.his.huawei.com (canpmsgout06.his.huawei.com [113.46.200.221]) (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 2A13A4252B1 for ; Tue, 7 Jul 2026 14:05:19 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=113.46.200.221 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1783433123; cv=none; b=EbZFcWF/+6VolonIHprDZ0qQfiqlP1UhL8MomMWcLGz5gPIsV4JrNcLqM7KzeghBxUWHCDTfHHEQBsGvn2XE/waXk3Z76jgTgAyatGkQZSkwEpJMKV0BRPl9cpjGhz5LP1sQn5oNoCW1lCwALwsFGr07b8PejFmjzWf3vamTvXQ= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1783433123; c=relaxed/simple; bh=hjmJzIz63znk6xz2U2ruy0nDJj0Fa6zHR5EFXrIS+CA=; h=From:To:CC:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version:Content-Type; b=TDRerDm2NSVgbJKrfM3v/jRYXAyuoQP2+efwjj8r56XB272xO5wMyCNVWk7yFgrvHzX8fEF9yXq2iFpirwIApBOxzhZYb9fJjUrNtOayiLrs3MlwnckWLVv8uGEDyd0R4SYewBk6ifKsNsR77nhP7McN/oxdpn3upjnu0I8YXCU= 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=mJPKBpcx; arc=none smtp.client-ip=113.46.200.221 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="mJPKBpcx" dkim-signature: v=1; a=rsa-sha256; d=huawei.com; s=dkim; c=relaxed/relaxed; q=dns/txt; h=From; bh=rm1KNibCz+ERMVqGQLvzK/uPua2K5RXP/Arqnz8w2t0=; b=mJPKBpcxf9F2zQUNY1YAPwDjh84VLxG9DD0UipCOkKffqTF7mV1KnXhZMlTlmx9xOOdCtaMC3 QlQyeTbwSLfO4/aKT4fx036hyhIlgMGxVUTr1eOp+Oyl6AAnVuzIMTOoYqxkHlALfXJBcBrvLHV A+zRKwOs4tBqIVq6Z+6ClaQ= Received: from mail.maildlp.com (unknown [172.19.163.104]) by canpmsgout06.his.huawei.com (SkyGuard) with ESMTPS id 4gvjS50jGFzRhRF; Tue, 7 Jul 2026 21:56:05 +0800 (CST) Received: from kwepemj100009.china.huawei.com (unknown [7.202.194.3]) by mail.maildlp.com (Postfix) with ESMTPS id 56D774057F; Tue, 7 Jul 2026 22:05:17 +0800 (CST) Received: from DESKTOP-A37P9LK.huawei.com (10.67.109.17) by kwepemj100009.china.huawei.com (7.202.194.3) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.1544.36; Tue, 7 Jul 2026 22:05:16 +0800 From: Xie Yuanbin To: , CC: , , , , , , , , , , , , , , , Subject: Re: [PATCH v3 1/2] ARM: mm: fix use-after-free in __do_user_fault() under CONFIG_DEBUG_USER Date: Tue, 7 Jul 2026 22:04:05 +0800 Message-ID: <20260707140405.85568-1-xieyuanbin1@huawei.com> X-Mailer: git-send-email 2.53.0 In-Reply-To: References: 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: kwepems500002.china.huawei.com (7.221.188.17) To kwepemj100009.china.huawei.com (7.202.194.3) On Tue, 7 Jul 2026 14:20:19 +0100, Lorenzo Stoakes wrote: > Well the whole reason you're faulting here might be because a userland process > did that right? The page tables should tell you (presumably on ARM32 :) > > And I hate to repeat myself, maybe you didn't read the whole thread but... just > use mmap_write_lock(), this isn't necessary? > > What is this trying to achieve? > > You're not in a hotpath, why are you bothering to conditionally take/not take > the lock? I think it is not the same thing as the previous discussion regarding which locks are needed for `show_pte()`. Now, for this bug, we have two places that need to be fixed: 1. __do_user_fault()->show_pte(); 2. do_DataAbort()->show_pte(); For the first one, it must be a user fault, the judgment of user_mode(regs) can be omitted. For the second one, it may be a user fault or a kernel fault. If it is a kernel fault, it also means that this is a kernel oops. For kernel oops, according to Russell's opinion, we do not need to fix this bug, which means we do not need to acquire any locks, because the kernel may die soon. However, show_pte() still needs to be retained because it is useful for debugging the kernel. For user faults, we need to fix it: 1. For user space addr (addr < TASK_SIZE), we need to acquire current->mm's write lock, before show_pte(), I understand it now. 2. For kernel space addr (addr >= TASK_SIZE), maybe we can omit show_pte()? After all, user-mode programs can access any kernel address to trigger user faults, but we dump the page tables of kernel addresses, would that be inappropriate, (e.g., posing potential security risks)?