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 E30F8D44161 for ; Tue, 19 Nov 2024 14:25:14 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 6F42E6B0096; Tue, 19 Nov 2024 09:25:14 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 67D556B0098; 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 546EB6B0099; Tue, 19 Nov 2024 09:25:14 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0016.hostedemail.com [216.40.44.16]) by kanga.kvack.org (Postfix) with ESMTP id 373B26B0096 for ; Tue, 19 Nov 2024 09:25:14 -0500 (EST) Received: from smtpin06.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay03.hostedemail.com (Postfix) with ESMTP id DB1FDA050F for ; Tue, 19 Nov 2024 14:25:13 +0000 (UTC) X-FDA: 82803064974.06.2B28007 Received: from dfw.source.kernel.org (dfw.source.kernel.org [139.178.84.217]) by imf20.hostedemail.com (Postfix) with ESMTP id 3655B1C0005 for ; Tue, 19 Nov 2024 14:24:09 +0000 (UTC) Authentication-Results: imf20.hostedemail.com; dkim=pass header.d=linuxfoundation.org header.s=korg header.b=jmz2ttKt; dmarc=pass (policy=none) header.from=linuxfoundation.org; spf=pass (imf20.hostedemail.com: domain of gregkh@linuxfoundation.org designates 139.178.84.217 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=TEJt5ZLUyi7GflsOFt0TAqXGGXGKnhOSHMtBkBlDP2YP/NtY5bbk4/JZ0NWJv0rMu3uGlg TuCo95xkZb7dPm3yP+DYz3a5SJBWE4LD4+Sjz2ifNLKXXYxxuTDDN5e6ifS7JOU5B1TdaO bdS8uZNLknWgGOE9h8YrQlN/iRV3xcg= ARC-Authentication-Results: i=1; imf20.hostedemail.com; dkim=pass header.d=linuxfoundation.org header.s=korg header.b=jmz2ttKt; dmarc=pass (policy=none) header.from=linuxfoundation.org; spf=pass (imf20.hostedemail.com: domain of gregkh@linuxfoundation.org designates 139.178.84.217 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=Jkvfuf+hQUWWQQvaNCTygJj3hlppUoZ3Q1YeCcWZXEQ=; b=T9CttyV/V3oPYpRraIKxEZXccxb3qIGjTL6CDTW1NVhmHlYVfvJ5Owr6yHGz8B1p2hOwDi qLkig8ahW2Cn47Zo3RL2uTaSe5Jda4dOI7PUiwGvmY0x/nvElfHd0bBIs11BrdqLfbi/wo SCOss0YVtEWHF9r2Ge8FWrVoIXK+3J8= Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58]) by dfw.source.kernel.org (Postfix) with ESMTP id 11F205C540D; Tue, 19 Nov 2024 14:24:27 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id B069BC4CECF; Tue, 19 Nov 2024 14:25:10 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1732026310; bh=SRIa8J9xZhdb/Ao++DobUsc6NJf+xEfjm/XpdCz8MH8=; h=Subject:To:Cc:From:Date:In-Reply-To:From; b=jmz2ttKtjKjiJthdaVzPsfMWkxr0ztYmFT1t4iB5A7U9MUq95p+XRxFxXCC7IoH4l 9QK72X6iBFtThN7kUMato1zM9xhDD+PnFUTpqJLo5kZ/sF2A9DzYN9a8VaveZrsZ9G 0tuGV+C0I2VPgF80867Axn2Kn7j6KgIrME2hfRA4= Subject: Patch "mm: unconditionally close VMAs on error" 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: Message-ID: <2024111938-work-appease-851a@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: 3w8mwfwgabp5kndquu44zyoik8knjzna X-Rspamd-Queue-Id: 3655B1C0005 X-Rspamd-Server: rspam08 X-Rspam-User: X-HE-Tag: 1732026249-10466 X-HE-Meta: U2FsdGVkX18YhtsaIgSfIGPaMBjsEUubiFap3A7w+3FNj/OCG81kU0MlbtmHGAdO9HeWOt0qVmccuGjlM28MVi/eB9RcOXwWoJxSShCzHoRzvAM0PapzRoZg+8Dy5JjytvxpdwzTgRVBeVyZNVTSzChfuFuI6T89/wp4CFAoWcSjBU9SWE2HrSKQ7vmbhg6/lAJ1dBuwkTiaMiQI4eZ8V1jCP45mP2EcXCsBvhI/C2EJhN/jq+B9hI2fZvehzHwSia9GIOEOewrFnaP9v+ATVGd28qMhryy6oGcw/R3KLFSLrDbqXt88XgGWikNpStmAP0ASdEAhmmGP3irIeb3S1bM2T8YJ9/45Af6OCp5rd3DPCf0hPXZlCF23TCgnWfH073SOH1zK1MM9KjZbGOTGNWPnRbHSYHeJEfgwhAnOrJX4qoLCqe5Sz6acTNMCQD4y7WumvZcQl3E0npHRdU0sW0HocDcbsmBUWQg9Pd53uVc1NkBe9CCF5HZB3J15PoTzbsRD9HCX2xa4hirMUcmiXIpIfKXtT3cp6t1tLa36REUdnRB0oLhF6NGqLo+tXE8Znevg1ChLL/CtHg7yXsxQQCEQ/xq50YJzFRbFkIGxw6xE0KqdzHPpt4Q0UUHNfkQi4h9lT/v/2vfje6i0p4AdgG6vA6ONpK1xuuVamWfTaN4dsDeeo2hXja60uGBPRCpRtblf/9FJH/I1Td/u7QplKSQvjRjHdg1eIWWpQqOYF9NMzRgqEfy93KTKL3qy6DOrw2sklFC6RrK9nogPdEaNKspwCjh3eUGkUuqv+89w0YrP/CEYZZO7mW6oIfgjU2AKWyxxToSSCTVbyAnRUVXKcID/vrA/pIDI8v9kA/SUNQk2vkKTFR98gvBh6ov37GHnKYD8Jasa+VsGkZe3cIf+5f7msULrOwTlNJlnucn3vClk5oKurXX71f24YwL+ejdvW5kLkeG8rfEgDGxaUHC ic/m6rLd F2mVrGRLmbqJnWO+X864c8yTRF32dpruk7XpA/Tq2tiVH1A5ka9w8ewTD4vOV6N6KXEBJ0JpfVo+qBmbERJh1OBMm8FDQKeOHIKJCWiTA/IiwA7TD1zAJAVt8xykmKNYY0PDAdXqHKDxH0ZkOPqAXlGyU1iGKKcQoGDyKpAqTdHCwnUz66qPTlczOuHLdTt4/2DeTF9GAqYFem6n9u9QNW/un5TyW/K5ZEsDr1gLaH63wlOakBL1u8sVqSMORJ+uxApgV2C9KAyTD7wUtZYAOSL+VTxt+4N9c4tC9Iw+ddhn/i2PBqhgVPYI5fkprs9xTNl7a1Rl3dBDXkNcxPkdBM6ETdI4HtLa7/XRDjemRuYPyMhye1icBNzBnLNoGsOqpTLmyypBAxXaNNi+vMuVP+6PSYzrwdDRNipvGSTMd3UimPsNM1P9HVbuWe9dZn5U8Uti8xitSX4aXNMZRmnq4QPOXAqgUajGzVhNxEGHMdIuZgGgeR1mbRvJ42A7TcKmWvcwzYutiJRuFXmoxxBQguBX1+BQudlBJgrpzwdWJFflBUQCrF6A50d8gMW5gDtEI55+RPvniqSKnsbfl7elbp2qsAru0SV43I/zHfleLVxGqBdop7kH6q7uwC41Ou6Vd39AKREffDbXqVKq+uGNiUtF4UVo/wKq52H1q9PLhyVhFfZYKCtNfBxPx3ybFWtoF9XNDDsg9tWyP8Z0uULauj+/Hmo9NVz06HT8w6DhFyXufG07pS9xSqb3wepb4d++U1MDiiYG85zrBkV22QoUqfLOnoLmVtJ6fTQeMA15ZNaEzsDk5uoCYGP43BxT4+j+bJd7NBk1aEOWKyGQEdEgOKFG7j0/hErDHeXG4iE+2mCjQFPU= 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: unconditionally close VMAs on error 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-unconditionally-close-vmas-on-error.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-93521-greg=kroah.com@vger.kernel.org Fri Nov 15 13:37:59 2024 From: Lorenzo Stoakes Date: Fri, 15 Nov 2024 12:36:52 +0000 Subject: mm: unconditionally close VMAs on error 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: From: Lorenzo Stoakes [ Upstream commit 4080ef1579b2413435413988d14ac8c68e4d42c8 ] Incorrect invocation of VMA callbacks when the VMA is no longer in a consistent state is bug prone and risky to perform. With regards to the important vm_ops->close() callback We have gone to great lengths to try to track whether or not we ought to close VMAs. Rather than doing so and risking making a mistake somewhere, instead unconditionally close and reset vma->vm_ops to an empty dummy operations set with a NULL .close operator. We introduce a new function to do so - vma_close() - and simplify existing vms logic which tracked whether we needed to close or not. This simplifies the logic, avoids incorrect double-calling of the .close() callback and allows us to update error paths to simply call vma_close() unconditionally - making VMA closure idempotent. Link: https://lkml.kernel.org/r/28e89dda96f68c505cb6f8e9fc9b57c3e9f74b42.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: Vlastimil Babka Reviewed-by: Liam R. Howlett 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 | 7 +++++++ mm/mmap.c | 9 +++------ mm/nommu.c | 3 +-- mm/util.c | 15 +++++++++++++++ 4 files changed, 26 insertions(+), 8 deletions(-) --- a/mm/internal.h +++ b/mm/internal.h @@ -46,6 +46,13 @@ void page_writeback_init(void); */ int mmap_file(struct file *file, struct vm_area_struct *vma); +/* + * If the VMA has a close hook then close it, and since closing it might leave + * it in an inconsistent state which makes the use of any hooks suspect, clear + * them down by installing dummy empty hooks. + */ +void vma_close(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 @@ -176,8 +176,7 @@ static struct vm_area_struct *remove_vma struct vm_area_struct *next = vma->vm_next; might_sleep(); - if (vma->vm_ops && vma->vm_ops->close) - vma->vm_ops->close(vma); + vma_close(vma); if (vma->vm_file) fput(vma->vm_file); mpol_put(vma_policy(vma)); @@ -1901,8 +1900,7 @@ out: return addr; close_and_free_vma: - if (vma->vm_ops && vma->vm_ops->close) - vma->vm_ops->close(vma); + vma_close(vma); unmap_and_free_vma: vma->vm_file = NULL; fput(file); @@ -2788,8 +2786,7 @@ int __split_vma(struct mm_struct *mm, st return 0; /* Clean everything up if vma_adjust failed. */ - if (new->vm_ops && new->vm_ops->close) - new->vm_ops->close(new); + vma_close(new); if (new->vm_file) fput(new->vm_file); unlink_anon_vmas(new); --- a/mm/nommu.c +++ b/mm/nommu.c @@ -662,8 +662,7 @@ static void delete_vma_from_mm(struct vm */ static void delete_vma(struct mm_struct *mm, struct vm_area_struct *vma) { - if (vma->vm_ops && vma->vm_ops->close) - vma->vm_ops->close(vma); + vma_close(vma); if (vma->vm_file) fput(vma->vm_file); put_nommu_region(vma->vm_region); --- a/mm/util.c +++ b/mm/util.c @@ -1091,3 +1091,18 @@ int mmap_file(struct file *file, struct return err; } + +void vma_close(struct vm_area_struct *vma) +{ + static const struct vm_operations_struct dummy_vm_ops = {}; + + if (vma->vm_ops && vma->vm_ops->close) { + vma->vm_ops->close(vma); + + /* + * The mapping is in an inconsistent state, and no further hooks + * may be invoked upon it. + */ + vma->vm_ops = &dummy_vm_ops; + } +} 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