From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by smtp.lore.kernel.org (Postfix) with ESMTP id 7476BD44162 for ; Tue, 19 Nov 2024 14:25:17 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id E71046B0098; Tue, 19 Nov 2024 09:25:14 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id E1F726B009B; Tue, 19 Nov 2024 09:25:14 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id C75D06B009E; Tue, 19 Nov 2024 09:25:14 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0012.hostedemail.com [216.40.44.12]) by kanga.kvack.org (Postfix) with ESMTP id 929E06B0098 for ; Tue, 19 Nov 2024 09:25:14 -0500 (EST) Received: from smtpin01.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay06.hostedemail.com (Postfix) with ESMTP id 41C09AD754 for ; Tue, 19 Nov 2024 14:25:14 +0000 (UTC) X-FDA: 82803064344.01.9366A3B Received: from nyc.source.kernel.org (nyc.source.kernel.org [147.75.193.91]) by imf30.hostedemail.com (Postfix) with ESMTP id 8046980016 for ; Tue, 19 Nov 2024 14:23:37 +0000 (UTC) Authentication-Results: imf30.hostedemail.com; dkim=pass header.d=linuxfoundation.org header.s=korg header.b=fLTlJs8Q; dmarc=pass (policy=none) header.from=linuxfoundation.org; spf=pass (imf30.hostedemail.com: domain of gregkh@linuxfoundation.org designates 147.75.193.91 as permitted sender) smtp.mailfrom=gregkh@linuxfoundation.org ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1732026128; a=rsa-sha256; cv=none; b=Sa9kz22sYqN1pFk8loz13gl1wvTwRaoyfUZCc8Oij8PeFjFU2GHBct0nQevXbbLfBQ7kOF CI2zDiZxz492z5GhL0Y2aAcGxfQ2qzNUtAH6pbaq6Kp5d/2vp796Kx5nRmbVrf5oojozAw 7ZwNpo6kUxgTsDVu48FZQ4dAmk9aJg8= ARC-Authentication-Results: i=1; imf30.hostedemail.com; dkim=pass header.d=linuxfoundation.org header.s=korg header.b=fLTlJs8Q; dmarc=pass (policy=none) header.from=linuxfoundation.org; spf=pass (imf30.hostedemail.com: domain of gregkh@linuxfoundation.org designates 147.75.193.91 as permitted sender) smtp.mailfrom=gregkh@linuxfoundation.org ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1732026128; h=from:from:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:dkim-signature; bh=SMzjn2Cb3nLhMeqTOwO9/D+sfCl4iH6V+Bvr6N9nnag=; b=CdHe9JaSrRLxzIr5aHCl7E8OI1vwJ+cebmxYtL8QpFHZVxRrO/r1JzA9IFt+phrbQnoA+H kGVvKxFUV0+di9V08YtPWIT/aWjTz9xjqNbD/ewd+BhsiW5X/NYCr/w5oWcQCNMnCJhL21 Ip0AfYV/9T94kGindy4TnmoxuwbeXf8= Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58]) by nyc.source.kernel.org (Postfix) with ESMTP id 523A0A42ADB; Tue, 19 Nov 2024 14:23:18 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 71E90C4CECF; Tue, 19 Nov 2024 14:25:11 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1732026311; bh=dXLi4tg3sK6motVWqV5IKzK4GkEEq6wpUr8ysB8P3Sw=; h=Subject:To:Cc:From:Date:In-Reply-To:From; b=fLTlJs8QzLzOdqbVhh3cbuZHlREWvZIBNmnq0s/VBn+bGBZD4hjbb+9tBT2btw7hv tpTJTWGbfuDrR7iX+Tdb65U+h//OEzqSSZYY3MbrjPNWVXzcM6ZUISC5NHv+h+/yA2 cj91eLSJC6Y7BY2lQGedTAFUeCAul0rZiyHhvp8M= Subject: Patch "mm: resolve faulty mmap_region() error path behaviour" has been added to the 5.10-stable tree To: James.Bottomley@HansenPartnership.com,Liam.Howlett@oracle.com,akpm@linux-foundation.org,andreas@gaisler.com,broonie@kernel.org,catalin.marinas@arm.com,davem@davemloft.net,deller@gmx.de,gregkh@linuxfoundation.org,jannh@google.com,linux-mm@kvack.org,lorenzo.stoakes@oracle.com,peterx@redhat.com,torvalds@linux-foundation.org,vbabka@suse.cz,will@kernel.org Cc: From: Date: Tue, 19 Nov 2024 15:24:38 +0100 In-Reply-To: <99f72d6dc52835126ca6d2e79732d397f6bfa20b.1731670097.git.lorenzo.stoakes@oracle.com> Message-ID: <2024111938-crown-uncork-64a7@gregkh> MIME-Version: 1.0 Content-Type: text/plain; charset=ANSI_X3.4-1968 Content-Transfer-Encoding: 8bit X-stable: commit X-Patchwork-Hint: ignore X-Stat-Signature: 8bpguwf6or8yhbyktcx4t1ocwh1x7dfk X-Rspamd-Queue-Id: 8046980016 X-Rspamd-Server: rspam08 X-Rspam-User: X-HE-Tag: 1732026217-978307 X-HE-Meta: U2FsdGVkX18DUSL5c5JwUtEvP3od+PbVjU+17vue6zOcRp4PbBmUcakR0jj8MkXOIFnwzhJEPw8QSgcbT4lZC51Bf8076bOn/FJwqwFKet727dEMNVP0u6gicu80V4Qj7Rtx34zVYQVbi4FBcZ6h0Yfyg7pK/AK53j7GnGct4UVDpu59kkT5Li9ojnjAhvuQpP27W/D9MxD3db6K+YyA9KCucJM2KmLTxh4jRTVycYL5wye2FIEwfHlU+PPU/hgMfOjKum83hiErhpNGUHlvUPYIXZGXK1yXoiPNfmbkIKCmTJLb5JLzc6WYYgO6J5leQqrdHicvx1zMowRr80TmmFHNhcsl8pxVnCerQUfhBlEap2LNQxMMBGb+vjCcJ6V6oEM6utOgBFi8y0SykrluXWrdDBHLlrNnpe8/FKWAJ/u/+1ILnLHnPwPfLzJRFDHEezPglbtA/+6sHsLi/tPhlnLLfEaD26Prz70xhjLZAMxQ2lj/dSNci+qAzk+np7m3sGk2vxeqFBFwYydpGJwZ+gKsd4bZnYYczHNtETw4Wrk/yXFfYXPCuRKmRABhzu11v9yqer/9k7Er73OfWcMG4NKzioVMfdudkgVFqo8qcwx9IN4RuoyVn1B9ka30cYOudv79Di9G4IFrzm27dmyssQmMW7FY+33WYTMmAd6V+L/7947LKgxy3fVR819TWvp2cOBY5ri15j5Ga6xkHRG/poIxo7B1FapP8f9MzfPa97X6/gqb/DNtqj1W13zx5xk/TI0BUugJ8X45MNHNybAEXTMsfV0LShd7KIaW2pkc3x+Ka2/9OJwJp/PvMa2MYFetI0YP87oBviJScJd1NYw4ewGLtTG97HgWSQnfu1jWI/suf6XrOFmkgEM0PlPsw0524qTLhIUnLr7McxSjBkrclWh0BU/AtPBzhlE9hqKfEjmBUXWtPd4M5QRUwEkjHzFm0Lopo3o9CWtThkUxJ17 BlmdUKqV 6Uao1tB6iX4oNUgzkD2qhCb5m4BhmS1MZkiYJOjyr2Whv5xEryH0XLtvw2tYY7E3QkBVaMn4GfHQL/CimsYuFe/we+ZCOwPHKZd2eV4J5QL+q/F00SkrNxHi31t1VCe+FNuZvMkCM127772bBwg2wZsyCND9xEJrQ1m5BFIHgzUaxl0q7mdRuxqtWwabAwsfXu3rxl0afB6CBonP3qatpiaYkvCXBhm3hzZuvZ3CyBza9gugE2236hpsr4ECe8Z2XhQU98bJ2n+jlX/x97WzYLYZE9tZdbR8FapyAsUcfEXkzMskfrjIl/fZpraB+0ctb3ZEXamMfpTddD6FxePX7hal0jxXdU/ANJ+z8d7K8wlHm8IBNN1C6tRct61ymrQtiqJ10W+jfDTHlIZcFzDObQhXIQwZ8+EscEDRkl5ZruLcj8tE3A83oju8PdIREnYDiNa5grRFrMwHPb//cHKEntc9mofpNysV5aKTpvWj8Xafz0C8ChEktjluYkGSmZzDAhmOv/JSucpqH4vWTRSt6KmPpgRpkMR00imvkADGiFNKy5I3BvlLLcMXICzAXAK4EsFaHgJgitiNX5IyDVyhHK6ahTHTRp8VcDiNyA7XSUVQdgFUjjrdz8EUXtv/DU/N5k/mwlmStdLM2J1q/BTbscyiyrgHRyFr9yDGbyFGHSJ/eqvDbaT6LlW26Pde9iwQ+xSOlyLM6ho+TTFjDJbmk5H1v0FE9x+KRXdhwcUQ7F3Wt6Z2F6sZA2ZMurbMxekyttiel0MwNwh7AguXj3OnuQs6FphfxPhg0uJDX1boZLbpzIVyz5tqy72oOijHBCs0RYgKL0Vv8TnzrWy9ga4RqoNnufLX/Ltg2PG12vPS83enf4cbcCi/Xs8mkLQ== X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: List-Subscribe: List-Unsubscribe: This is a note to let you know that I've just added the patch titled mm: resolve faulty mmap_region() error path behaviour to the 5.10-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=summary The filename of the patch is: mm-resolve-faulty-mmap_region-error-path-behaviour.patch and it can be found in the queue-5.10 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let know about it. >From stable+bounces-93523-greg=kroah.com@vger.kernel.org Fri Nov 15 13:38:45 2024 From: Lorenzo Stoakes Date: Fri, 15 Nov 2024 12:36:54 +0000 Subject: mm: resolve faulty mmap_region() error path behaviour To: stable@vger.kernel.org Cc: Andrew Morton , "Liam R . Howlett" , Vlastimil Babka , Jann Horn , linux-kernel@vger.kernel.org, linux-mm@kvack.org, Linus Torvalds , Peter Xu , Catalin Marinas , Will Deacon , Mark Brown , "David S . Miller" , Andreas Larsson , "James E . J . Bottomley" , Helge Deller Message-ID: <99f72d6dc52835126ca6d2e79732d397f6bfa20b.1731670097.git.lorenzo.stoakes@oracle.com> From: Lorenzo Stoakes [ Upstream commit 5de195060b2e251a835f622759550e6202167641 ] The mmap_region() function is somewhat terrifying, with spaghetti-like control flow and numerous means by which issues can arise and incomplete state, memory leaks and other unpleasantness can occur. A large amount of the complexity arises from trying to handle errors late in the process of mapping a VMA, which forms the basis of recently observed issues with resource leaks and observable inconsistent state. Taking advantage of previous patches in this series we move a number of checks earlier in the code, simplifying things by moving the core of the logic into a static internal function __mmap_region(). Doing this allows us to perform a number of checks up front before we do any real work, and allows us to unwind the writable unmap check unconditionally as required and to perform a CONFIG_DEBUG_VM_MAPLE_TREE validation unconditionally also. We move a number of things here: 1. We preallocate memory for the iterator before we call the file-backed memory hook, allowing us to exit early and avoid having to perform complicated and error-prone close/free logic. We carefully free iterator state on both success and error paths. 2. The enclosing mmap_region() function handles the mapping_map_writable() logic early. Previously the logic had the mapping_map_writable() at the point of mapping a newly allocated file-backed VMA, and a matching mapping_unmap_writable() on success and error paths. We now do this unconditionally if this is a file-backed, shared writable mapping. If a driver changes the flags to eliminate VM_MAYWRITE, however doing so does not invalidate the seal check we just performed, and we in any case always decrement the counter in the wrapper. We perform a debug assert to ensure a driver does not attempt to do the opposite. 3. We also move arch_validate_flags() up into the mmap_region() function. This is only relevant on arm64 and sparc64, and the check is only meaningful for SPARC with ADI enabled. We explicitly add a warning for this arch if a driver invalidates this check, though the code ought eventually to be fixed to eliminate the need for this. With all of these measures in place, we no longer need to explicitly close the VMA on error paths, as we place all checks which might fail prior to a call to any driver mmap hook. This eliminates an entire class of errors, makes the code easier to reason about and more robust. Link: https://lkml.kernel.org/r/6e0becb36d2f5472053ac5d544c0edfe9b899e25.1730224667.git.lorenzo.stoakes@oracle.com Fixes: deb0f6562884 ("mm/mmap: undo ->mmap() when arch_validate_flags() fails") Signed-off-by: Lorenzo Stoakes Reported-by: Jann Horn Reviewed-by: Liam R. Howlett Reviewed-by: Vlastimil Babka Tested-by: Mark Brown Cc: Andreas Larsson Cc: Catalin Marinas Cc: David S. Miller Cc: Helge Deller Cc: James E.J. Bottomley Cc: Linus Torvalds Cc: Peter Xu Cc: Will Deacon Cc: Signed-off-by: Andrew Morton Signed-off-by: Lorenzo Stoakes Signed-off-by: Greg Kroah-Hartman --- mm/mmap.c | 69 ++++++++++++++++++++++++++++++++++++++++---------------------- 1 file changed, 45 insertions(+), 24 deletions(-) --- a/mm/mmap.c +++ b/mm/mmap.c @@ -1726,7 +1726,7 @@ static inline int accountable_mapping(st return (vm_flags & (VM_NORESERVE | VM_SHARED | VM_WRITE)) == VM_WRITE; } -unsigned long mmap_region(struct file *file, unsigned long addr, +static unsigned long __mmap_region(struct file *file, unsigned long addr, unsigned long len, vm_flags_t vm_flags, unsigned long pgoff, struct list_head *uf) { @@ -1795,11 +1795,6 @@ unsigned long mmap_region(struct file *f if (error) goto free_vma; } - if (vm_flags & VM_SHARED) { - error = mapping_map_writable(file->f_mapping); - if (error) - goto allow_write_and_free_vma; - } /* ->mmap() can change vma->vm_file, but must guarantee that * vma_link() below can deny write-access if VM_DENYWRITE is set @@ -1809,7 +1804,7 @@ unsigned long mmap_region(struct file *f vma->vm_file = get_file(file); error = mmap_file(file, vma); if (error) - goto unmap_and_free_vma; + goto unmap_and_free_file_vma; /* Can addr have changed?? * @@ -1820,6 +1815,14 @@ unsigned long mmap_region(struct file *f */ WARN_ON_ONCE(addr != vma->vm_start); + /* + * Drivers should not permit writability when previously it was + * disallowed. + */ + VM_WARN_ON_ONCE(vm_flags != vma->vm_flags && + !(vm_flags & VM_MAYWRITE) && + (vma->vm_flags & VM_MAYWRITE)); + addr = vma->vm_start; /* If vm_flags changed after mmap_file(), we should try merge vma again @@ -1851,21 +1854,14 @@ unsigned long mmap_region(struct file *f vma_set_anonymous(vma); } - /* Allow architectures to sanity-check the vm_flags */ - if (!arch_validate_flags(vma->vm_flags)) { - error = -EINVAL; - if (file) - goto close_and_free_vma; - else - goto free_vma; - } +#ifdef CONFIG_SPARC64 + /* TODO: Fix SPARC ADI! */ + WARN_ON_ONCE(!arch_validate_flags(vm_flags)); +#endif vma_link(mm, vma, prev, rb_link, rb_parent); - /* Once vma denies write, undo our temporary denial count */ if (file) { unmap_writable: - if (vm_flags & VM_SHARED) - mapping_unmap_writable(file->f_mapping); if (vm_flags & VM_DENYWRITE) allow_write_access(file); } @@ -1899,17 +1895,12 @@ out: return addr; -close_and_free_vma: - vma_close(vma); -unmap_and_free_vma: +unmap_and_free_file_vma: vma->vm_file = NULL; fput(file); /* Undo any partial mapping done by a device driver. */ unmap_region(mm, vma, prev, vma->vm_start, vma->vm_end); - if (vm_flags & VM_SHARED) - mapping_unmap_writable(file->f_mapping); -allow_write_and_free_vma: if (vm_flags & VM_DENYWRITE) allow_write_access(file); free_vma: @@ -2931,6 +2922,36 @@ int do_munmap(struct mm_struct *mm, unsi return __do_munmap(mm, start, len, uf, false); } +unsigned long mmap_region(struct file *file, unsigned long addr, + unsigned long len, vm_flags_t vm_flags, unsigned long pgoff, + struct list_head *uf) +{ + unsigned long ret; + bool writable_file_mapping = false; + + /* Allow architectures to sanity-check the vm_flags. */ + if (!arch_validate_flags(vm_flags)) + return -EINVAL; + + /* Map writable and ensure this isn't a sealed memfd. */ + if (file && (vm_flags & VM_SHARED)) { + int error = mapping_map_writable(file->f_mapping); + + if (error) + return error; + writable_file_mapping = true; + } + + ret = __mmap_region(file, addr, len, vm_flags, pgoff, uf); + + /* Clear our write mapping regardless of error. */ + if (writable_file_mapping) + mapping_unmap_writable(file->f_mapping); + + validate_mm(current->mm); + return ret; +} + static int __vm_munmap(unsigned long start, size_t len, bool downgrade) { int ret; Patches currently in stable-queue which might be from lorenzo.stoakes@oracle.com are queue-5.10/mm-resolve-faulty-mmap_region-error-path-behaviour.patch queue-5.10/mm-refactor-arch_calc_vm_flag_bits-and-arm64-mte-handling.patch queue-5.10/mm-unconditionally-close-vmas-on-error.patch queue-5.10/mm-avoid-unsafe-vma-hook-invocation-when-error-arises-on-mmap-hook.patch