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=1794598484; b=vlvC7QjHgIhO804xK3S4jG6Bjb9KgOGw+H5qoX8AFRnGctGtb2AhXZntFo4F/WfwgKnM T5aC2ZwIwvnUY3DSFUwWb4zandMII5V8b+GzQPLi88a3ZQ55ww7WYjBA+THH84Z/VZNtS jcdTMq/AyvOySS5esWBAUqJGMTO47Jly7MH1w1D7qv2isjhm6IobOh6yxA34jAa6xbqJI jZG1VbxpPdgCaJPerofOPewHXhIX7OGI/QsIbFBLOz6MQxWm4NQ3G9StTE0HCSeK2KpsR Mf2Gp3KT683B3iLcyE3ncUimnFOCdFJ9wa+RBU0Zbw904FuHULluD7aeIl2MJ0YJxug== ARC-Message-Signature: i=1; d=subspace.kernel.org; s=arc20261015; a=rsa-sha256; c=relaxed/relaxed; t=1794598484; h=Received:DKIM-Signature:From:To:Cc:Subject:Date:Message-ID:X-Mailer: In-Reply-To:References:MIME-Version:Content-Transfer-Encoding; bh=KqwnOJltiqbNiZbmEj6MJnIguzlqCZ7mZruEGLOFPPM=; b=4NfLKvG3rZ9kf97EnTpAE9pu5setJ0eAL6QloZZElakmOe9XTrF9EOQ+qCc6ZvH8eJhm f1pg02pw78i1rqJqahj21WZCrweZJyhJILD0gHyit/TlgUjL9i/SDRVd0UyoTA39+KJuf DaR+nIBQ8mArmmnfYvsCK9O62AJ9VJ+mpY6MjfmHma/DeazYa2j+krr4b6b1NN+yTXu09 B9lYlXFzbQAkCXC10anaDTpMmX+xqBKjn1yDQSiK0M3UxxKLTfgIeygm98rE/KfRz4E4Z SarsiQa6bigwdCTNsrWQG0+Z/LJ7QwcNvyZyGUH1LRvUrSvp3pMHMFwNk4Z8Ad5p5yQ== ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass header.d=kernel.org header.i=@kernel.org header.a=rsa-sha256 header.s=k20260515 header.b=SZRr8FKi; 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 ED72C606A333 for ; Fri, 13 Nov 2026 19:34:43 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.a=rsa-sha256 header.s=k20260515 header.b=SZRr8FKi Received: by smtp.kernel.org (Postfix) with ESMTPSA id 19C341F000C5; Fri, 13 Nov 2026 19:34:43 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kernel.org; s=k20260515; t=1794598483; bh=KqwnOJltiqbNiZbmEj6MJnIguzlqCZ7mZruEGLOFPPM=; h=From:To:Cc:Subject:Date:In-Reply-To:References; b=SZRr8FKi+m8kqYdFUMI/rZjct/gb9mgYto7Dov34/A2+TviR/lW2uXpZZYsEV0gIj aO9jlisf+iQhMDvqHZ5xJ/Rp4SEkAZsi5AeCEIJNi749fqfInYzV786UfehM+MTDmY YijyhKPIeMeNRCMrCEvf1KYjY++J/Jur/8Fb6DRHa691RoT+D7EFoF0eAebWc0CtA8 wM6vFjS9N1mJ8Ry0Zo/+4sVEdJOgjurVH0fT4xsEnGEFrWsJmXi4qvtH/sq3HLwqh+ pIGzQyoK0UCXRpxbP4H3SRQ/iRf4zw8dhHpvxkg5ho0c39oYLoc8AJORQ1p9e3qAeg N9PFwLl1q9aJw== From: Sasha Levin To: stable@vger.kernel.org Cc: Chris Mason , "Lorenzo Stoakes (ARM)" , Pedro Falcato , Muhammad Usama Anjum , "David Hildenbrand (Arm)" , Sasha Levin Subject: [PATCH 6.6.y 2/2] mm/memory: reject remote COW faults on PFN mappings Date: Fri, 13 Nov 2026 14:34:41 -0500 Message-ID: <20261113192843.2425959-2-sashal@kernel.org> X-Mailer: git-send-email 2.53.0 In-Reply-To: <20261113192843.2425959-1-sashal@kernel.org> References: <20261109201352-failed-6.6-8db6921cc07b@kernel.org> <20261113192843.2425959-1-sashal@kernel.org> X-Mailing-List: stable@vger.kernel.org List-Id: List-Post: List-Help: List-Subscribe: List-Unsubscribe: List-Owner: Precedence: list MIME-Version: 1.0 Content-Transfer-Encoding: 8bit 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 2ad125baa9504..a3f48457a2446 100644 --- a/mm/memory.c +++ b/mm/memory.c @@ -2837,6 +2837,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 @@ -3127,6 +3134,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