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 BCB86D44161 for ; Tue, 19 Nov 2024 14:26:30 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 943FD6B00B6; Tue, 19 Nov 2024 09:26:23 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 8F13C6B00B8; Tue, 19 Nov 2024 09:26:23 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 742D76B00B9; Tue, 19 Nov 2024 09:26:23 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0017.hostedemail.com [216.40.44.17]) by kanga.kvack.org (Postfix) with ESMTP id 4C3A56B00B6 for ; Tue, 19 Nov 2024 09:26:23 -0500 (EST) Received: from smtpin20.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay06.hostedemail.com (Postfix) with ESMTP id 0FDE1AD85E for ; Tue, 19 Nov 2024 14:26:23 +0000 (UTC) X-FDA: 82803066318.20.10B10DF Received: from dfw.source.kernel.org (dfw.source.kernel.org [139.178.84.217]) by imf08.hostedemail.com (Postfix) with ESMTP id CA7F716001D for ; Tue, 19 Nov 2024 14:25:47 +0000 (UTC) Authentication-Results: imf08.hostedemail.com; dkim=pass header.d=linuxfoundation.org header.s=korg header.b=hPhUMiGg; dmarc=pass (policy=none) header.from=linuxfoundation.org; spf=pass (imf08.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=1732026290; 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=EE0qkgsX/7ZN7naCNxA19+Lxa3DjI2f/IM7QQpnfm6s=; b=uUmEEYiftxjb7o9U4kB1IJSllMgQg+Qz8xcS8uUfrNNvRJVdBEbDiM+NsYU7ghN17V6Nka JMXS/aT8N8PBFUmDcx9xM99rIbDpVrY0UnjgrradH+gWDaKBFXuLv2/cMwNk/BE+j3CF6e 6k/FMyEHA+YHq1sA2TqYFNgvhb00c/M= ARC-Authentication-Results: i=1; imf08.hostedemail.com; dkim=pass header.d=linuxfoundation.org header.s=korg header.b=hPhUMiGg; dmarc=pass (policy=none) header.from=linuxfoundation.org; spf=pass (imf08.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=1732026290; a=rsa-sha256; cv=none; b=WhmSA5uho+DXZOTed82UeV1kz0/BxRxXHF1eLP7Afe7Fqu69T3zU70LK3PyNgGsaPoBKS0 mE0RxkjMNfK1vpnuW6Zyb+ZKOhCKdoHAMnmdn4npSsHsjFSgbQbpeaUPz82XaH5/9RicNs 6rCwFH3QnpEgnRIqrdywFIr5jnWih4A= Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58]) by dfw.source.kernel.org (Postfix) with ESMTP id A81155C10A5; Tue, 19 Nov 2024 14:25:36 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 4E690C4CED7; Tue, 19 Nov 2024 14:26:20 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1732026380; bh=df7itNEOH7w2OpgReOwEViZyoS4/XJrzt+OjfHcnPHY=; h=Subject:To:Cc:From:Date:In-Reply-To:From; b=hPhUMiGgLn4QQ8nJ8oscAnCJqeJH2zyEXoPJUDHKxDZWPpb4hhFZI462ZLD+1b0MV YwoUoRRRIycXrWBfqCPa/jjDBYeTzt3XJaraFKWgsGYGYvMaLfK97Onk08RQdHZKzT tzaoCJyq8yoyDZv4sfrXJ6Yk+1VNVyN7U+8FdJYg= Subject: Patch "mm: unconditionally close VMAs on error" has been added to the 6.6-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:25:46 +0100 In-Reply-To: Message-ID: <2024111946-hypertext-deforest-0e5a@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: rspam03 X-Rspamd-Queue-Id: CA7F716001D X-Stat-Signature: s17yiigsyguquy4e81jkt8ctimpfpeoi X-HE-Tag: 1732026347-326141 X-HE-Meta: U2FsdGVkX18cHbX11iso26I/MhyRNpO3JHqqDXYd0Hb0Qr0snryZ9g2XcQuELujcT0XIzioJBguWe+34rz8QbMyxaXJgjbGw2Fm/9NdvNK/v6BGSv/OwfeXrcmxYLvSJPQL3jBzcnDJC7p1KbG2zC+qmdSYWGoAzxGGhSmnVVsD3HAYw+XiSHefMifDVU8FhusFG+nYnkzykKoXYJtLNjDSyp7j7TFwzfzA92SkkpqrAqoEUwb+UFR2hdKaPfV3i2UAWktzmcLzCragCjMgxcs9PJ7RsYKE5uu5V4BUxCoJQDLxCX7LVkxr1oaaA1RFQ2HqYieN2xOruB6PS32wUGZHchkklg0kj1gI9bB2Ujp622b0/h603AenpHjfIXIdF8XiOq2HpMOj22Ei1f2h+YFYmUQF+gM3BUreqS3q+R3NsAF4yq8pOnUhffUD3AA/g2RAZsZb7+WtxCstwDdDcw+udkMLFzYfk2jApGVzz2FvjxYxYdcm7AA/pdswQYKtLRFUnTjZ1cLFWW8yn0v8aUeMlhzCu9TabndyzWCZdl6ZPg39ft5jrEse5oWgRUmvo6NsuY3BHc6FMRlIoEXWzJgKjkFWE7z38v1HaeTt/RyhrfrCiHbZ0FrIXKIa/1ewfLCM9nQxu6G+YjG5MoIgSxz4xzbKNsCO7U814WSW0FmYeAqhL3hXvSU9bltKDpFJfGFpAmheIeoHiwh3WVieTZJ3oaxgw8j0BJ3VT0cuVH3UWHFfeC5s6JJI+jOBlykPNEyKMrsGy/s98cQvfVJhMYDkWyNBFUDh/fKWNbVutdq4ZF69MyhVnnIfhmqV3cO2IVykvh156sspPoU2Zw4PqY5/Va8AMqBkVKrmsr3KNBv69hbXZVN1jYeR3fAPHabdlRtOJM17UL5CfJ1mxRnYZA7khLCz+fTx36APzOnERcRYMej/qX9WYgVcy40GjoQeRK7T2nukDhDu08bx19Wp eODENW7s Ti6oE4xaGE97CxgJJ6ntLQTBE9/kWIELe5paGlI9eUzL/DpOhv88wIe0oD2FVWlssPRRct6k+i0+theLJgBEfdInQq9UqPlVEwFnML9JEpCuyrbJlfsq2+OKI4LMbPdfumwdjl6gtr9fft/fO2x+plsYhRbYQhJ1Tve4n7QnKABzTMnz4/j8fiFWd4VBxA2yirIZV6YWxjEeYqpebVORMK03bmaQuLatKAuuFhv36fI88AvjI6IKw5YHotHo3VNqV+cKNQgsbKEkdRlauck954HV9YL6nRzlsckD6iA2hgz8msPWmjC0gTWwaRTAd2EVbw5zbNZbGKlp/pBcHL4o0HzSXGQ1p/XLJVrmJxm+ecIEUOWZ1dth+2DJDrOeeAX2oem5ZFPAQcBnONkBKDV9Lbr6dclFB540M8sz80Fs6Ax+AVOsq6bXM9GBjnFj2cDa3D4FhueaAXqaYLekx4Wg4wngWDLC7uQ/6kq3EeXI4GYLg6CLwwrBrNGdSM1I5+IFeife3ATOsuU/lUwAzG4Kxax6vHm96jf1IBBKpVWLCnvUdBnztOe0NDEL3JkDkQhrIRD1J77SbgcBZzpf6hePS6/nFoW2/oEiNcH8/8cEpMLcOTKfQQhjhr2vSedCAWfwBj1wiNhsl02fIIsqjAqSRFwgvhlzC63p9glfZzja82ziKfEbWhIuLmhXbBY2xjlMuuqAwprIkIEoyLwx2D9X6Lpe4iZZ/hQoJyAGF6jxiOCwCW0HpjyEQ6cgUBPCWqHJzCMHO3JTrgNGkYcS+g2jytyajmcKDLyUsX5Atn07swS8tEq+VGkLUXHOJk9+CSOVW5OP0S2JnCUs1l3KYbOUZYg55zb4UH8Qd++NYYkpskXMW2ss= 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 6.6-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-6.6 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let know about it. >From stable+bounces-93536-greg=kroah.com@vger.kernel.org Fri Nov 15 13:42:55 2024 From: Lorenzo Stoakes Date: Fri, 15 Nov 2024 12:41:55 +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 | 18 ++++++++++++++++++ mm/mmap.c | 9 +++------ mm/nommu.c | 3 +-- 3 files changed, 22 insertions(+), 8 deletions(-) --- a/mm/internal.h +++ b/mm/internal.h @@ -110,6 +110,24 @@ static inline int mmap_file(struct file return err; } +/* + * 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. + */ +static inline void vma_close(struct vm_area_struct *vma) +{ + 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 = &vma_dummy_vm_ops; + } +} + void __acct_reclaim_writeback(pg_data_t *pgdat, struct folio *folio, int nr_throttled); static inline void acct_reclaim_writeback(struct folio *folio) --- a/mm/mmap.c +++ b/mm/mmap.c @@ -137,8 +137,7 @@ void unlink_file_vma(struct vm_area_stru static void remove_vma(struct vm_area_struct *vma, bool unreachable) { 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)); @@ -2899,8 +2898,7 @@ expanded: return addr; close_and_free_vma: - if (file && vma->vm_ops && vma->vm_ops->close) - vma->vm_ops->close(vma); + vma_close(vma); if (file || vma->vm_file) { unmap_and_free_vma: @@ -3392,8 +3390,7 @@ struct vm_area_struct *copy_vma(struct v return new_vma; out_vma_link: - if (new_vma->vm_ops && new_vma->vm_ops->close) - new_vma->vm_ops->close(new_vma); + vma_close(new_vma); if (new_vma->vm_file) fput(new_vma->vm_file); --- a/mm/nommu.c +++ b/mm/nommu.c @@ -600,8 +600,7 @@ static int 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); Patches currently in stable-queue which might be from lorenzo.stoakes@oracle.com are queue-6.6/mm-resolve-faulty-mmap_region-error-path-behaviour.patch queue-6.6/mm-refactor-arch_calc_vm_flag_bits-and-arm64-mte-handling.patch queue-6.6/mm-unconditionally-close-vmas-on-error.patch queue-6.6/mm-avoid-unsafe-vma-hook-invocation-when-error-arises-on-mmap-hook.patch queue-6.6/mm-refactor-map_deny_write_exec.patch