From mboxrd@z Thu Jan 1 00:00:00 1970 Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.remote-ip=100.103.45.18 ARC-Seal: i=1; d=subspace.kernel.org; s=arc20261015; a=rsa-sha256; cv=none; t=1794591196; b=BL0dk9f3dFc2z8R1tdw1lyVpl2m+urr+Vc3pmIeA4RtCzOAChfAghAf4MIOgovOddmBd 6dcIW0TipB99lpxFqo8Z4CtTjB53uTTGgWaAKkP6DpHymavyvBzF69G5P3y7E/AFNatAO 7y39hIXqPgM60eXvYlQIZyVLwJuf1cHU9f90Yr8sFAkesUvudWqzQeM+Hfk7gO44hBPqN xJRpzYP+A6+C5h4MmOYekIAOMROvKEMwiq+/OScdlEEcrlXhJVMDUbnvgOlGdCbp7cKBH ci1IsuXXVdwQ1Qg/iqrKZK74Q8xci+9TNGnlcMOS+fL5XCgPCQNrI9FEyS3zhCXNLRQ== ARC-Message-Signature: i=1; d=subspace.kernel.org; s=arc20261015; a=rsa-sha256; c=relaxed/relaxed; t=1794591196; h=Received:DKIM-Signature:From:To:Cc:Subject:Date:Message-ID:X-Mailer: In-Reply-To:References:User-Agent:X-stable:X-Patchwork-Hint: MIME-Version:Content-Transfer-Encoding; bh=XYEfLIsHVrX9WmezlDyYAR2vnQm4JheiKC4cugyh0PQ=; b=jUXSkPDVdf7SOZOUJOodWwVwGwzhha5AmksiM7wXkRAkzAEtthDISxdCGEvDheoEEzCs tJhTgT0divug9GEkaDHTIoTDY8VKaaE5vquS0tbGZqUp/HN8OyPUJk/eiJc6+XPmn42Xv mBtBf9/BHMHjYYpb+e6gkiHaHSK60KTXavY8z3EAeyy2qDzzYU8OS7GfR3Mc1bLiD4BlM uVmWvb8mgKGTsgzO95vd6cP0CH7x4TnjemCGNdydAWdec9bYJIeJCrtLWs031qM5PG1YS Y+2I6DNkWExU+JJVz5Dgj8aA7JFUnFBhSwGXZ2EGss+f6qBeRYeIIpgUC/fZAQKMZ9g== ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass header.d=linuxfoundation.org header.i=@linuxfoundation.org header.a=rsa-sha256 header.s=korg header.b="BliZjXo/"; arc=none smtp.remote-ip=100.103.45.18 Received: from smtp.kernel.org (quasi.space.kernel.org [100.103.45.18]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature ECDSA (prime256v1)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id ADAE96075846; Fri, 13 Nov 2026 17:33:16 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=linuxfoundation.org header.i=@linuxfoundation.org header.a=rsa-sha256 header.s=korg header.b=BliZjXo/ Received: by smtp.kernel.org (Postfix) with ESMTPSA id 13B421F000C4; Fri, 13 Nov 2026 17:33:16 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linuxfoundation.org; s=korg; t=1794591196; bh=XYEfLIsHVrX9WmezlDyYAR2vnQm4JheiKC4cugyh0PQ=; h=From:To:Cc:Subject:Date:In-Reply-To:References; b=BliZjXo/Sr2x88kszU1MJ6tbOVyy5ztINxqie0zCgWE+AnNPK47BXKTylWLxaKHsT krMbCqcx3fK5UJNp9V0LD3kQuwR/ibbfPYVQJbXITOU+rLrINXlnMjEL2Cgg/pwZal QWAJ3TaWa+JGrPiUTuTWBCyUdkTgd9gkxh+Rosus= From: Greg Kroah-Hartman To: stable@vger.kernel.org Cc: Greg Kroah-Hartman , patches@lists.linux.dev, Chris Mason , "Lorenzo Stoakes (ARM)" , Pedro Falcato , Muhammad Usama Anjum , "David Hildenbrand (Arm)" , Sasha Levin Subject: [PATCH 6.12 330/670] mm/memory: reject remote COW faults on PFN mappings Date: Fri, 13 Nov 2026 10:48:14 -0500 Message-ID: <20261113153823.058653979@linuxfoundation.org> X-Mailer: git-send-email 2.56.0 In-Reply-To: <20261113153811.177190860@linuxfoundation.org> References: <20261113153811.177190860@linuxfoundation.org> User-Agent: quilt/0.69 X-stable: review X-Patchwork-Hint: ignore X-Mailing-List: patches@lists.linux.dev List-Id: List-Post: List-Help: List-Subscribe: List-Unsubscribe: List-Owner: Precedence: list MIME-Version: 1.0 Content-Transfer-Encoding: 8bit 6.12-stable review patch. If anyone has any objections, please let me know. ------------------ From: Chris Mason [ Upstream commit 8db6921cc07b74197a3866d62ed262b68aeadcf3 ] When handling a COW fault without a normal source page (PFN mappings), __wp_page_copy_user() copies from the faulting user address. For remote faults, this accesses the wrong address space, resulting in wrong data getting copied. For example, user_events updates an enable bit in the registering process's memory. If that memory needs to be faulted in, user_event_enabler_fault_fixup() calls fixup_user_fault() from a work item. Placing the enable bit in a private PFN mapping can trigger this remote COW path. Reject these faults with VM_FAULT_SIGBUS when the target mm differs from current->mm: remote faults. Ordinary (non-PFN) mappings are not affected. The user-address copy dates back to commit 6aab341e0a28 ("mm: re-architect the VM_UNPAGED logic"); likely, actual ways to get remote faults in there on COW PFN mappings appeared afterwards. But the fix is simple and straight forward. Fix generated by an LLM and sent by Chris Mason in private. Fixes: 6aab341e0a28 ("mm: re-architect the VM_UNPAGED logic") Cc: stable@vger.kernel.org Signed-off-by: Chris Mason Reviewed-by: Lorenzo Stoakes (ARM) [ david: simplify comment and description ] Reviewed-by: Pedro Falcato Tested-by: Muhammad Usama Anjum Link: https://patch.msgid.link/20261031-fixes_core-v3-35-d6437171ecc3@kernel.org Signed-off-by: David Hildenbrand (Arm) Signed-off-by: Sasha Levin --- mm/memory.c | 9 +++++++++ 1 file changed, 9 insertions(+) diff --git a/mm/memory.c b/mm/memory.c index c493f18cfb3ab..81e5e9cadc35f 100644 --- a/mm/memory.c +++ b/mm/memory.c @@ -3046,6 +3046,13 @@ static inline int __wp_page_copy_user(struct page *dst, struct page *src, return 0; } + /* + * __copy_from_user_inatomic() only works as expected for local faults. + * Reject remote faults. + */ + if (unlikely(mm != current->mm)) + return -EFAULT; + /* * If the source page was a PFN mapping, we don't have * a "struct page" for it. We do a best-effort copy by @@ -3371,6 +3378,8 @@ static vm_fault_t wp_page_copy(struct vm_fault *vmf) folio_put(old_folio); delayacct_wpcopy_end(); + if (err == -EFAULT) + return VM_FAULT_SIGBUS; return err == -EHWPOISON ? VM_FAULT_HWPOISON : 0; } kmsan_copy_page_meta(&new_folio->page, vmf->page); -- 2.53.0