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=1794630899; b=j6PJ4iRvD/WkIKcHY28F3kfNbyfyE9HjO7Hax+Px5caa+w+H2RB+md8Ccw9FSNdOH62a RxZeOai6ghaGQHo/h4mAONAPkCg9xoVUjkuac0HVoNq8ivsrN54PZT92K9sB+aBB1qrnj ZlGoL+Y/a+9WGyULli8vpQZT7VVLvbNJ/q+mZ76wRkBgxmtkqhOIGZBMC8WEOvZKNjGEI yAeFIb6eMWWI5sZqW+whcqqauIXk1YMiIrTtVVAWHr/lnypD5Anm3w/3KkdiZwLWxo6qL b6o6RXsN9ogx/R35A/7erxN6GvgOXQiROO0AMkE6LI3As+kIBLcVO8R0c51tjhyqWQw== ARC-Message-Signature: i=1; d=subspace.kernel.org; s=arc20261015; a=rsa-sha256; c=relaxed/relaxed; t=1794630899; h=Received:DKIM-Signature:From:To:Cc:Subject:Date:Message-ID:X-Mailer: In-Reply-To:References:MIME-Version:Content-Transfer-Encoding; bh=z1dI1lwhC/v1AtDh5bc2rZ68x9BVam9BM/VhZAp6kG4=; b=fWeYkSfaTcBHBi2vyxe9esCUmScqK4FNq5zg01o5IWtDMAC8axmyMLC3YD7nZuqu7HjC kSldTASFRMGrMPMJ7L7b9w67ez3q5FBXkL5W4nUzsjYf6I7pSePaqajbcrktrwoCKFmNe SXcirLy4jcspMx4Kpmx0+IgtTA/17+NiXZTla1FAWBDLA98v014TQsjYG1v1AaBRJ6WH9 Ny+e8zHovPRAmH6rAxZf52kYlFPyIDrAzZrwQaaBjuZatUP0JjWzDwFxiyHijH5+a+Ncu pgpUIh/MWzo2iX6cXX/6yTrqRVuLjzt6IP42KCaKRP+fD26et3Ri5oRhMv9c+epd27w== 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=eEGcrLdk; 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 7B196606A327 for ; Sat, 14 Nov 2026 04:34:59 +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=eEGcrLdk Received: by smtp.kernel.org (Postfix) with ESMTPSA id 53D0A1F000C4; Sat, 14 Nov 2026 04:34:58 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kernel.org; s=k20260515; t=1794630899; bh=z1dI1lwhC/v1AtDh5bc2rZ68x9BVam9BM/VhZAp6kG4=; h=From:To:Cc:Subject:Date:In-Reply-To:References; b=eEGcrLdk2oZxkDBsHySMVc2jAiwT0bXhtVzeWKw3jjRYuJYizO/dJ99eRIJ0jVs2G 6EboGyEC02FiCw0ZnHy9m3z5JSCiYbCl8czFshQ1C8Z11p69l6bBPV/dCtUZpVYoG5 jmN+iwWXBfXrpxRU+8l8ekytZZAFQjGtDTMKEWQ4YBULqtMsJlYAAiUpnVZ4tCsnuQ ALyP3KtbqMXJFNkuTTPoGc+iP065gR1ogu/ppMYYUey2/pp0sKJItGGQzbz0GLqejC 7PPthmNxoOeB45x3syOitqCAjTKWe4BqGZ42Xi/8hZibDWr/JOKkl3Lpr/ZqRoSJzY i2o6486HYJFAQ== 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 5.15.y] mm/memory: reject remote COW faults on PFN mappings Date: Fri, 13 Nov 2026 23:34:57 -0500 Message-ID: <20261114035329.2627555-1-sashal@kernel.org> X-Mailer: git-send-email 2.53.0 In-Reply-To: <20261109202346-failed-5.15-8db6921cc07b@kernel.org> References: <20261109202346-failed-5.15-8db6921cc07b@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) [ sashal: adapted wp_page_copy() error handling to use ret instead of err ] 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 4ca2f4c076a9a..b8882b1f9d75c 100644 --- a/mm/memory.c +++ b/mm/memory.c @@ -2808,6 +2808,13 @@ static inline int cow_user_page(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 @@ -3071,6 +3078,8 @@ static vm_fault_t wp_page_copy(struct vm_fault *vmf) if (old_page) put_page(old_page); + if (ret == -EFAULT) + return VM_FAULT_SIGBUS; return ret == -EHWPOISON ? VM_FAULT_HWPOISON : 0; } } -- 2.53.0