From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-alma10-1.taild15c8.ts.net [100.103.45.18]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id BF6FF4E9C3E; Fri, 9 Oct 2026 14:44:58 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=100.103.45.18 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1791557099; cv=none; b=Cal60U+6ULnnTtEmKI7ZzmLuDtHpdLewVW3NP49q0OeT29LB8qwqnafCVjNuX06zdDlSXuLiXkj4DkpMTj9uBbVsSmklObCvv+s2LXAKJKh8oGS3dVKQVr+875b+tsLtFFnk4RGylBySECehRoSX4f1Iim43+as+fzZwTfxT6EQ= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1791557099; c=relaxed/simple; bh=hektFdn+yiPUAKuBspSWeBB62B8s95yagv0AMWbK1sQ=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=skIadjMI0LwOcj9PcjGZSO03D9SAyokbIiHFixl+T4GgufwJGanXvEGGdI14RQD+X6PgxBDJ2qGZtoDEgLq42Bg8vP8CCOLGQO5Kex988H/ySUd/U1B4lY+FuRURTeDeNHxIhap1grm9CpflwVYJ0HEXhBvQSG4NFtEkkP8I2z8= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=linuxfoundation.org header.i=@linuxfoundation.org header.b=08N7kYtA; arc=none smtp.client-ip=100.103.45.18 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=linuxfoundation.org header.i=@linuxfoundation.org header.b="08N7kYtA" Received: by smtp.kernel.org (Postfix) with ESMTPSA id C988A1F000FF; Fri, 9 Oct 2026 14:44:57 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linuxfoundation.org; s=korg; t=1791557098; bh=dZ3aji5kziB0gQ1nr85xNP9D3rnzoknrH7WzL3UjtKo=; h=From:To:Cc:Subject:Date:In-Reply-To:References; b=08N7kYtAm3ChF7S/b2PKmkw5qpZN6DmbIkcK1SkJHE+yYxl59SCyY9v273wZdFtLD O+xGn7bMhaJZ6ekWhrQdGH/CqHT3UYfHUFXn4CsuZ5Ec2SRZ9lRB2ZuWEtdW0NZc56 Xskjpc85AT6N6+v7OhdqJ2oJJJTqMGf0OPW0HTy0= From: Greg Kroah-Hartman To: stable@vger.kernel.org Cc: Greg Kroah-Hartman , patches@lists.linux.dev, "Lorenzo Stoakes (ARM)" , Andrew Morton , Suren Baghdasaryan , "Gregory Price (Meta)" , Zi Yan , "Vlastimil Babka (SUSE)" , "Liam R. Howlett" , Jann Horn , Pedro Falcato , Sasha Levin Subject: [PATCH 6.18 346/403] mm/vma: predicate setting mmap_prepare VMA fields on new vma alloc Date: Fri, 9 Oct 2026 16:11:47 +0200 Message-ID: <20261009141000.358971514@linuxfoundation.org> X-Mailer: git-send-email 2.56.0 In-Reply-To: <20261009140952.119038291@linuxfoundation.org> References: <20261009140952.119038291@linuxfoundation.org> User-Agent: quilt/0.69 X-stable: review X-Patchwork-Hint: ignore Precedence: bulk X-Mailing-List: patches@lists.linux.dev List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: 8bit 6.18-stable review patch. If anyone has any objections, please let me know. ------------------ From: Lorenzo Stoakes (ARM) [ Upstream commit 976d5e0ddac885b0219252f004f6c561c344df9d ] It only makes sense to manipulate VMA fields if a new VMA was allocated, rather than merged. VMA merging does not compare vm_ops or vm_private_data, so a merged VMA keeps its own, which is also what the legacy f_op->mmap path does since it never touches an existing VMA. Currently, these fields will get overwritten by whatever state is established in the mmap_prepare hook, and if the VMA was merged, vm_ops->mapped will not have been called, so this could destructively clear existing state without replacing it with anything valid. There is an implicit requirement that vm_private_data and vm_ops are fungible across VMAs which means that losing the 'new' state is fine. However in this case the 'old' state is being overwritten by potentially invalid 'new' state, so this must be rectified. Additionally constify have_mmap_prepare while here. All existing in-tree users either derive state from the file or are unmergeable due to VMA flags, so this has no direct impact. Link: https://lore.kernel.org/20260923-fix-mmap-prepare-overwrite-v1-1-3b3f1bfcdf5e@kernel.org Fixes: c84bf6dd2b83 ("mm: introduce new .mmap_prepare() file callback") Signed-off-by: Lorenzo Stoakes (ARM) Signed-off-by: Andrew Morton Reviewed-by: Suren Baghdasaryan Reviewed-by: Gregory Price (Meta) Acked-by: Zi Yan Acked-by: Vlastimil Babka (SUSE) Cc: Liam R. Howlett Cc: Jann Horn Cc: Pedro Falcato Cc: Signed-off-by: Sasha Levin --- mm/vma.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/mm/vma.c b/mm/vma.c index d160cc6a608af..d1158fdcde287 100644 --- a/mm/vma.c +++ b/mm/vma.c @@ -2693,7 +2693,7 @@ static unsigned long __mmap_region(struct file *file, unsigned long addr, { struct mm_struct *mm = current->mm; struct vm_area_struct *vma = NULL; - bool have_mmap_prepare = file && file->f_op->mmap_prepare; + const bool have_mmap_prepare = file && file->f_op->mmap_prepare; VMA_ITERATOR(vmi, mm, addr); MMAP_STATE(map, mm, &vmi, addr, len, pgoff, vm_flags, file); bool allocated_new; @@ -2727,7 +2727,7 @@ static unsigned long __mmap_region(struct file *file, unsigned long addr, goto unacct_error; } - if (have_mmap_prepare) + if (have_mmap_prepare && allocated_new) set_vma_user_defined_fields(vma, &map); __mmap_complete(&map, vma); -- 2.53.0