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 68ED9D44162 for ; Tue, 19 Nov 2024 14:25:05 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id DF8236B0083; Tue, 19 Nov 2024 09:25:04 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id DA8796B0089; Tue, 19 Nov 2024 09:25:04 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id C70956B008C; Tue, 19 Nov 2024 09:25:04 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0013.hostedemail.com [216.40.44.13]) by kanga.kvack.org (Postfix) with ESMTP id A5EC56B0083 for ; Tue, 19 Nov 2024 09:25:04 -0500 (EST) Received: from smtpin01.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay05.hostedemail.com (Postfix) with ESMTP id 518134029F for ; Tue, 19 Nov 2024 14:25:04 +0000 (UTC) X-FDA: 82803063924.01.9901439 Received: from nyc.source.kernel.org (nyc.source.kernel.org [147.75.193.91]) by imf05.hostedemail.com (Postfix) with ESMTP id 759E510000A for ; Tue, 19 Nov 2024 14:23:27 +0000 (UTC) Authentication-Results: imf05.hostedemail.com; dkim=pass header.d=linuxfoundation.org header.s=korg header.b="K0TUl//K"; spf=pass (imf05.hostedemail.com: domain of gregkh@linuxfoundation.org designates 147.75.193.91 as permitted sender) smtp.mailfrom=gregkh@linuxfoundation.org; dmarc=pass (policy=none) header.from=linuxfoundation.org ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1732026153; 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=qZIB+M4FN12aM/6FIRwuzw2L+0e3DLzWlRO8aJk4t1g=; b=V2NGXD3lD7/jAKxceuSj8z3omYhzN4D+Ydi0ArdKPyic1q6ZUcVIQ++4AS0YAL0q1XWEXo 61h+qm0MobzIVslkQzwv5GqAsvB7Nygbn2aGx556o0LdVomi+0ZhvQ28LL+gqe13yctc1Z Cyy+4rlAHI8BFbpaflKP2LzXZnEV6MY= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1732026153; a=rsa-sha256; cv=none; b=ZYFDNfglsWcP0jOm8JNqbEeKSnrfP+bABnsDtWNluubB+NpRADha6Es06UwRFon4ux808t 5dfACoxPy+AS4ki/BleBBV/o7wv5WAKu8Vq1f/jI0ZJbPKcVvUxlqhrIBijC7vXrMvWP+i kwzKVIg37cWSbcQYzIcRbebAU2wPvuw= ARC-Authentication-Results: i=1; imf05.hostedemail.com; dkim=pass header.d=linuxfoundation.org header.s=korg header.b="K0TUl//K"; spf=pass (imf05.hostedemail.com: domain of gregkh@linuxfoundation.org designates 147.75.193.91 as permitted sender) smtp.mailfrom=gregkh@linuxfoundation.org; dmarc=pass (policy=none) header.from=linuxfoundation.org Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58]) by nyc.source.kernel.org (Postfix) with ESMTP id 5A0CBA42A9A; Tue, 19 Nov 2024 14:23:08 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 68C48C4CED9; Tue, 19 Nov 2024 14:25:01 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1732026301; bh=YVbBzwYQdo1coqIw5b13fyiudR/rgbwc3iIhXhPWZWQ=; h=Subject:To:Cc:From:Date:In-Reply-To:From; b=K0TUl//KBDfWfZ/c5V1xKQ8UJU+6NoYTo/6OivocbdEf9I79r32azqEuDAaAueNhI dALIKrykxcAqyIEEFZCUbnZ1geoxcTYvqVhe6GpZEds67ec9p9PBi8R3Oygo8Sqmbz w44HudFwqCFddtHqp2eo1o6xTzIOy3cpicu2x8Mg= Subject: Patch "mm: avoid unsafe VMA hook invocation when error arises on mmap hook" 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:37 +0100 In-Reply-To: <3a4ff9ebcc085e0074711ae883fa5ea11e6d7a8e.1731670097.git.lorenzo.stoakes@oracle.com> Message-ID: <2024111937-regress-pacifist-65e9@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-Rspam-User: X-Rspamd-Server: rspam12 X-Rspamd-Queue-Id: 759E510000A X-Stat-Signature: 9fdzrehmjjh9j8oz81n187cab3ypjy77 X-HE-Tag: 1732026207-279939 X-HE-Meta: U2FsdGVkX1+Pa7wNmp0gMJXvT0AP3HIE2xgvmsH44w0gx1egXHf0VzBm3zHwtonUc9vP65lr+72evbSAOQ+T53c/5mMgpSHf2I0WFsGGb8osRlmCfbQYrCbZtvMO16RkkYR27no6JhEE0tcOjXDTXOzj5u37MMPfjZailBfdTZ31htel5ZSt9N63+krW8E0FrNQU/26W6sOEyQ11xwvveote8eL0hpSpPzyzJdYBtIk2xMZ9ayb/JyZU1LVI2B9h4IHKrAP+3Sm/7BkxLPaQEBc6PENy5Ej+EbmyKYvV63sy+HVZDJa+rbKk8cWmzugQoKb9rTN6+/fix3oWAU+qX/gRau21rloJAMi4RUEzWzOhCSGax+crGR+N9MVOPP9Y4eyzKdni+n5gi1wpbSfNCx/PwGR87uWbAcHpBXFzBdRnC454YPpzqJJbwwZyeXrjpWP7zAzbpS6hTXahsfaOfAq9y90DRtXmCvvc75a5f/FJxg9OBDAYLVnT/r5VxZUcDLbxpKlqwsfa48bGUHfkV9+1bXEwciDpuAok3Vqq5E0l61gCJaHE9yZ0wNRUZ3FT2yToLJr9vmgRHrlaqn7p9nsvAVjL8jAm582G7iTKIbGlhdxHUnKQBNbFapcacbYcu3eyyElPCsLzVVLwN3WiTpnLwLwWJr/0bYueRiV7XcY0E5JJ/tbeCkZkcNzZN4IpUTwqHHRzW6zsuaI/cBtrCdndN/b9gUjE8V8h5Sf4fVItsnW0eJDUuaBPCk7hwI5VgfBT5i0pIeeY/uh9RY6hEHif7p5FE91AE39azXYmZ6YuY6inSeVP63DtKzgMCL8VxOGIPfrAfJKy9+2a6JkejMWsYm5wPIC9ifmu6hG+C30Gp+dPk1E+kyWecVGivXv3FTmofy/2xdU8ybgNFt48gsW43sD9pRAOkn0EdrANVQhBofc0mLLQOPDBmqnZe0D5o64tXtlLYHLm2djAvEt qyz2kgby rkJT2Cr1IEe4UeaASDGxeWcvHYU2fL9eWnqt0JTGH2NQ2vbJwN+2mFakoUrHZ7FJ+IQhr9i1HqKVu3ggwGDRKbXlLmE7AHREb7vK2TfTFsWBKK6FPtcilVJDPCvHMvBXuXilzZ+t95kOhPlZ0i6IQeNoHGdQRXVHdSapHCkSCRxpQjSWwo3U6n03CVUGYDFXSVefIG2m1nsndU+BQp9GJxtRBzT58TsSboUXl/yd0VxhWiJPe7zwSsZPR+FLlzFWPJKvSr6rVYU7zE6ZY5j/i2j9k7QZD1E4FE0BaOYvKb5k3AIT82iqy2bkcyozEipb1qx/Ql+S8HIQ6argiSIxWuqsXzPsYJPnlrgcQ+w3nbxFdjbd2ljehiW0QCIdBLGp9P06rzkgQkr+Cx/svQANTHS+ej2Qi9rigNwvOwmFlzy+azYD5eBSf1tz9f2xu58B+7iiWH/7C2YQcxa/Wx+9B48NmWXxlsgU6hj4rVVpZVpzqJIHFCRvHDCqOCvuxBdZsj4WB3mjXL7bS60X9kHYKcATUYtDTO7qQOb9/+baAhb5blnNyBbLIThvc9Kv1V7WBK4GqXNEy2VrJj9v/P7aQWLMv2WmeXjzd1eUqmWGfchkh/6sEQpC6thz3oOv61zA0Q/h5SkBI+1+n8tTOWdNGy5QEpiw++QIeqiXkJbmJUHkqK83tmw9g4UjbkK4ONdtXQMXj5yuEMYRX2idjXqFbpmsmkoZgEgY45PPy85E/nf3eF9eyp/ls1/shnOZKhiUB+4UkbNy6uCRI5usYqsY7xtB75JDRzq1/XekHymLHiY7r+TAvzwE+soYKtnHFsK20xu319kYoWdeCwio= 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: avoid unsafe VMA hook invocation when error arises on mmap hook 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-avoid-unsafe-vma-hook-invocation-when-error-arises-on-mmap-hook.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-93520-greg=kroah.com@vger.kernel.org Fri Nov 15 13:37:55 2024 From: Lorenzo Stoakes Date: Fri, 15 Nov 2024 12:36:51 +0000 Subject: mm: avoid unsafe VMA hook invocation when error arises on mmap hook 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: <3a4ff9ebcc085e0074711ae883fa5ea11e6d7a8e.1731670097.git.lorenzo.stoakes@oracle.com> From: Lorenzo Stoakes [ Upstream commit 3dd6ed34ce1f2356a77fb88edafb5ec96784e3cf ] Patch series "fix error handling in mmap_region() and refactor (hotfixes)", v4. mmap_region() 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. This series goes to great lengths to simplify how mmap_region() works and to avoid unwinding errors late on in the process of setting up the VMA for the new mapping, and equally avoids such operations occurring while the VMA is in an inconsistent state. The patches in this series comprise the minimal changes required to resolve existing issues in mmap_region() error handling, in order that they can be hotfixed and backported. There is additionally a follow up series which goes further, separated out from the v1 series and sent and updated separately. This patch (of 5): After an attempted mmap() fails, we are no longer in a situation where we can safely interact with VMA hooks. This is currently not enforced, meaning that we need complicated handling to ensure we do not incorrectly call these hooks. We can avoid the whole issue by treating the VMA as suspect the moment that the file->f_ops->mmap() function reports an error by replacing whatever VMA operations were installed with a dummy empty set of VMA operations. We do so through a new helper function internal to mm - mmap_file() - which is both more logically named than the existing call_mmap() function and correctly isolates handling of the vm_op reassignment to mm. All the existing invocations of call_mmap() outside of mm are ultimately nested within the call_mmap() from mm, which we now replace. It is therefore safe to leave call_mmap() in place as a convenience function (and to avoid churn). The invokers are: ovl_file_operations -> mmap -> ovl_mmap() -> backing_file_mmap() coda_file_operations -> mmap -> coda_file_mmap() shm_file_operations -> shm_mmap() shm_file_operations_huge -> shm_mmap() dma_buf_fops -> dma_buf_mmap_internal -> i915_dmabuf_ops -> i915_gem_dmabuf_mmap() None of these callers interact with vm_ops or mappings in a problematic way on error, quickly exiting out. Link: https://lkml.kernel.org/r/cover.1730224667.git.lorenzo.stoakes@oracle.com Link: https://lkml.kernel.org/r/d41fd763496fd0048a962f3fd9407dc72dd4fd86.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 Reviewed-by: Jann Horn Cc: Andreas Larsson Cc: Catalin Marinas Cc: David S. Miller Cc: Helge Deller Cc: James E.J. Bottomley Cc: Linus Torvalds Cc: Mark Brown Cc: Peter Xu Cc: Will Deacon Cc: Signed-off-by: Andrew Morton Signed-off-by: Lorenzo Stoakes Signed-off-by: Greg Kroah-Hartman --- mm/internal.h | 12 ++++++++++++ mm/mmap.c | 4 ++-- mm/nommu.c | 4 ++-- mm/util.c | 18 ++++++++++++++++++ 4 files changed, 34 insertions(+), 4 deletions(-) --- a/mm/internal.h +++ b/mm/internal.h @@ -34,6 +34,18 @@ void page_writeback_init(void); +/* + * This is a file-backed mapping, and is about to be memory mapped - invoke its + * mmap hook and safely handle error conditions. On error, VMA hooks will be + * mutated. + * + * @file: File which backs the mapping. + * @vma: VMA which we are mapping. + * + * Returns: 0 if success, error otherwise. + */ +int mmap_file(struct file *file, struct vm_area_struct *vma); + vm_fault_t do_swap_page(struct vm_fault *vmf); void free_pgtables(struct mmu_gather *tlb, struct vm_area_struct *start_vma, --- a/mm/mmap.c +++ b/mm/mmap.c @@ -1808,7 +1808,7 @@ unsigned long mmap_region(struct file *f * new file must not have been exposed to user-space, yet. */ vma->vm_file = get_file(file); - error = call_mmap(file, vma); + error = mmap_file(file, vma); if (error) goto unmap_and_free_vma; @@ -1823,7 +1823,7 @@ unsigned long mmap_region(struct file *f addr = vma->vm_start; - /* If vm_flags changed after call_mmap(), we should try merge vma again + /* If vm_flags changed after mmap_file(), we should try merge vma again * as we may succeed this time. */ if (unlikely(vm_flags != vma->vm_flags && prev)) { --- a/mm/nommu.c +++ b/mm/nommu.c @@ -955,7 +955,7 @@ static int do_mmap_shared_file(struct vm { int ret; - ret = call_mmap(vma->vm_file, vma); + ret = mmap_file(vma->vm_file, vma); if (ret == 0) { vma->vm_region->vm_top = vma->vm_region->vm_end; return 0; @@ -986,7 +986,7 @@ static int do_mmap_private(struct vm_are * - VM_MAYSHARE will be set if it may attempt to share */ if (capabilities & NOMMU_MAP_DIRECT) { - ret = call_mmap(vma->vm_file, vma); + ret = mmap_file(vma->vm_file, vma); if (ret == 0) { /* shouldn't return success if we're not sharing */ BUG_ON(!(vma->vm_flags & VM_MAYSHARE)); --- a/mm/util.c +++ b/mm/util.c @@ -1073,3 +1073,21 @@ int __weak memcmp_pages(struct page *pag kunmap_atomic(addr1); return ret; } + +int mmap_file(struct file *file, struct vm_area_struct *vma) +{ + static const struct vm_operations_struct dummy_vm_ops = {}; + int err = call_mmap(file, vma); + + if (likely(!err)) + return 0; + + /* + * OK, we tried to call the file hook for mmap(), but an error + * arose. The mapping is in an inconsistent state and we most not invoke + * any further hooks on it. + */ + vma->vm_ops = &dummy_vm_ops; + + return err; +} 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