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=1794590419; b=WCZRnvkVLDXPuakRN37icteNGeOCHFK7qzzj4WfpLdt4G/ehjaeyacLg0RDiBBpBbadT jSQlhjdRiL7+jWWrLGrj42m1TaW1cGpsLLyLC+oQHo2Hvxvi0TVsBlnUA2yzyyGJXfRvu kLHtN9JRt61Mb1LmSz8SPT7iMf+L84aREMr4AiI7J00rEzfEkac9hrJgKiDNXg0hQTXKC zXc9nXTaoohvzNTW2jtMHF7kq1TIvHZIXlfog0Jy0EJbZ20g/5mfBxE8GFzKw7vRrlFd1 zDpdCZOQimVoGKX4ptqldrDhgNKCNH+j6fQWo5HfWnM+CfFQxyaCBiBDHXLMHsxHgyQ== ARC-Message-Signature: i=1; d=subspace.kernel.org; s=arc20261015; a=rsa-sha256; c=relaxed/relaxed; t=1794590419; 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=nWkeHnqicgnoNZ9OVaslK0e+q5vtVBovCZvvKsQRwNk=; b=jonmSSGU2aIiYAN1xMbWNci8eac8YRBnl8fAQ4qYXEkjPaogLhydwJRDOjU7YZ9E6giL bZXvXvqP3P2U+e5oko0fhOgE5SaLy7TlEE1u9KlkVRRu/Gu/iqNpWRs+uSpxBHBKwBqvY UsqaGx6T44wK2B36R8tNzvzXs4fcr7DentN6AaqkM5RzwJ2thefrKdYsczvHfV5ait+DJ xUV/DFfKmYBdc49kkTRLpCY7X5jVGglrHgovKqFPx9lS76dAl/eV/JV66Ez8D7/bFLp4J FWyS1w1+bicLgqT2rNpqTE7IODXFpsojbuMc0unkQ/UIYKKE+fqvih1Fv5oBnbOVp2Q== 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=Q9sZ+mrJ; 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 65990606B46F; Fri, 13 Nov 2026 17:20:19 +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=Q9sZ+mrJ Received: by smtp.kernel.org (Postfix) with ESMTPSA id 157241F000C4; Fri, 13 Nov 2026 17:20:19 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linuxfoundation.org; s=korg; t=1794590419; bh=nWkeHnqicgnoNZ9OVaslK0e+q5vtVBovCZvvKsQRwNk=; h=From:To:Cc:Subject:Date:In-Reply-To:References; b=Q9sZ+mrJSeW+4g3PBxuAGQv3K+0dwBE0C5L5M6v6ZkyXuRqQW2PWcppiLrXP0XLRw pxL42iPnYlc5iv3w79ufkFtKAlHxgddMfJtfQmlQkQBLYIXbz4b+GWSydSz3WmcOeT AB9xte1nQ1xCkV5eDUD8sTRA/fVuPJ8YJETHKmz8= 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.18 383/686] mm/memory: reject remote COW faults on PFN mappings Date: Fri, 13 Nov 2026 10:48:36 -0500 Message-ID: <20261113153833.931484320@linuxfoundation.org> X-Mailer: git-send-email 2.56.0 In-Reply-To: <20261113153820.902362109@linuxfoundation.org> References: <20261113153820.902362109@linuxfoundation.org> User-Agent: quilt/0.69 X-stable: review X-Patchwork-Hint: ignore 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 6.18-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 01d14ca0e74d2..08dcd668c2d6b 100644 --- a/mm/memory.c +++ b/mm/memory.c @@ -3387,6 +3387,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 @@ -3712,6 +3719,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